Skip to main content

Search: #工程化

无原创,纯转发
  1. AI 时代怎么招工程师:Augment 的「AI-native」人才标准

    当 AI agent 能写出大部分代码后,工程师的价值开始上移:不再以“写得快、写得多”为核心,而是以判断力、系统设计与协同能力决定产出质量。

    Augment 重新梳理了面向 AI-native(与 AI 共同工作)团队的招聘标准,核心变化可以概括为一句话:人从“作者”变成“架构师与编辑”——定义意图、做取舍、设护栏、把好质量关。

    工程师工作重心的迁移

    • 传统工程:写代码、实现方案、解决问题、看个人产出
    • AI-native 工程:明确意图与权衡、编排 agent、选择正确问题、看系统级结果

    他们认为最重要的 6 个能力维度

    1. 产品与结果品味(Product & Outcome Taste):能否在代码变“更便宜”时,避免做出“最贵的错误”——把方向做错。
    2. 系统与架构判断(System & Architectural Judgment):代码能跑不难,难的是“能在生产环境长期稳定地跑”。
    3. Agent 杠杆(Agent Leverage):能否把 AI 变成真实吞吐量:拆解任务、引导偏航、验证结果(agent 很快,但也可能自信地出错)。
    4. 沟通与协作(Communication & Collaboration):实现更快后,“达成清晰”更关键;要能把意图讲清楚、促成共识。
    5. 主人翁意识与领导力(Ownership & Leadership):对结果负责而非只做任务;主动清除阻碍交付的障碍。
    6. 学习速度与实验心态(Learning Velocity & Experimental Mindset):工具三个月就变一轮,持续实验与快速迭代成为工作常态。

    一个显著的信号是:“纯粹的编码能力”不再是最主要的区分项——依然重要,但不再决定上限。

    从理念到招聘:看“可观察信号”

    他们强调,框架必须能落到面试里,转成可评估的行为证据,例如:

    • 能否快速澄清模糊问题、定义清晰目标?
    • 能否提前识别架构风险,而不是上线后救火?
    • 能否有效指挥并验证 AI 生成的工作?

    未来重点招的 4 类画像

    AI-native 系统工程师:基础设施与架构判断强,保证“地基”稳。
    AI-native 产品工程师:产品品味与用户理解强,确保“做对事”。
    AI-native 应用 AI 工程师:懂模型与应用构建,提升 agent 能力与工作流。
    AI-native 早期工程师(Early Professional):学习速度优先,快速适应工具与流程变化。

    这套标准也不只用于招聘,还会反向影响绩效、成长与职业发展:如果真正重视判断力、杠杆与学习速度,就应该在各个环节都体现出来。

    原文链接:https://www.augmentcode.com/blog/how-we-hire-ai-native-engineers-now

    #AI招聘 #工程师能力 #AI代理 #架构设计 #学习型组织 How we hire AI-native engineers now: our criteria
  2. GitHub Agentic Workflows:用自然语言写 GitHub Actions 的“智能工作流”

    GitHub 开源项目 gh-aw(GitHub Agentic Workflows),主打一个思路:用自然语言 Markdown 编写“代理式(agentic)工作流”,然后直接在 GitHub Actions 里运行,让 AI 代你完成仓库中的重复性任务。

    它提供的核心价值包括:

    更低门槛的工作流编写方式:用 Markdown 描述要做什么,而不是从零写复杂的 YAML/脚本
    更强调安全的执行模型(Guardrails):默认只读权限;写入操作需要通过经过清洗的 safe-outputs;并配套多层防护(输入净化、工具白名单、编译期校验、网络隔离、供应链安全等)
    完善的文档与上手路径:官方提供 Quick Start 与完整文档,方便快速跑通示例并理解整体机制
    生态配套
    AWF(Agent Workflow Firewall):限制与记录代理的网络访问(出站控制)
    MCP Gateway:统一转发 MCP(Model Context Protocol)服务调用,便于集中管理访问

    适合关注 AI + DevOps、希望把“AI 介入仓库日常操作”做得更可控、更工程化的团队参考与尝试(同时也要保持必要的人类监督)。

    原链接:https://github.com/github/gh-aw

    #GitHubActions #AI自动化 #工作流 #安全工程 #开源项目 GitHub - github/gh-aw: GitHub Agentic Workflows
  3. Agent-native 应用:把“功能”变成“结果”

    这篇文章提出一种新范式:与其把产品能力写成一堆固定功能,不如构建一个能反复调用工具、直到达成目标的“软件代理(agent)”。核心在于:让代理拥有与用户同等的操作能力(UI 能做的,代理也能通过工具做到),并把工具设计成足够原子化的“积木”。这样,新功能往往不再是写代码,而是写一段描述结果的提示词;同时,用户提出的意外需求会推动系统“涌现”出新用法,并反过来指导你补齐工具与能力缺口。

    五个核心原则

    对等(Parity):任何 UI 动作,代理都应能通过工具实现同样的结果;否则代理会卡死。
    粒度(Granularity):工具是原子能力;“功能”是代理在循环中用工具达成的结果。改行为优先改提示词,而不是重构代码。
    可组合(Composability):有了原子工具 + 对等能力,就能通过新提示词快速拼出新“功能”(开发者/用户都能做)。
    涌现能力(Emergent capability):用户会提你没设计过的需求;代理若能组合工具完成,就是新机会;若失败,则暴露工具缺口。
    持续变好(Improvement over time):通过沉淀上下文(context 文件)与迭代提示词,应用可在不发版的情况下持续变强。

    落地方法(把原则变成工程实践)

    先做“能力地图”:列出用户能做的事,逐项确认代理具备创建/读取/更新/删除(CRUD)能力,避免“能新建不能修改/删除”的断腿体验。
    先原语、后领域工具:先用文件、bash、读写等基础工具跑通;再为高频模式加领域工具,用于效率、校验、术语锚定,但不要把“判断”写进工具里。
    文件作为通用接口:文件天然可读、可审计、可迁移,代理也最擅长操作;内容放文件、结构化高频数据放数据库(或混合:文件作可读真相,DB 做索引与性能)。
    明确完成信号:不要靠“看起来差不多了”判断结束;让工具/编排层返回明确的 complete 信号,避免无限循环或半成品。
    透明的代理行为:工具调用、进度、状态变化要让 UI 可见;“沉默的代理”会让用户觉得坏了。
    把“授权”做成产品能力:根据风险与可逆性决定自动执行还是强确认;尤其是发送邮件、发布内容等高风险动作。

    对移动端的启示

    • 移动应用容易被后台杀死,代理任务却可能很长:需要checkpoint/恢复机制,尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”,但要处理冲突与未下载文件等边界。

    原链接:https://every.to/guides/agent-native

    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构 Agent-native Architectures
  4. GLM-4.7:把“能写代码”推进到“能当搭档”

    Z.ai 发布 GLM-4.7,主打更强的工程落地能力:不仅写得对,还更擅长在真实工作流里(Agent、终端、工具调用)稳定推进任务。

    这次重点提升了什么?

    核心编码与代理式开发:相较 GLM-4.6,在多语言 Agent 编程与终端任务上有明显提升;例如 SWE-bench Verified 73.8%(+5.8)SWE-bench Multilingual 66.7%(+12.9)Terminal Bench 2.0 41.0%(+16.5)。并强调在 Claude Code、Cline、Roo Code 等主流框架中更“好用”。
    Vibe Coding / UI 生成质量:更容易产出更现代、更干净的网页;做幻灯片时布局与尺寸更准确,整体观感更接近可直接交付的作品。
    工具使用能力:工具调用与浏览任务的表现增强(文中提到 τ²-Bench、BrowseComp 等基准),更适合“边查边做”的复杂流程。
    复杂推理与数学:推理能力提升,HLE(Humanity’s Last Exam)42.8%(+12.4,带工具),面向高难问题的稳健性更强。

    一个很实用的新变化:更可控的“思考”机制

    Interleaved Thinking:在回复/调用工具前先思考,提高指令遵循与产出质量。
    Preserved Thinking:在多轮编码代理场景中保留推理块,减少长任务里的信息丢失与前后不一致。
    Turn-level Thinking:按回合开关推理:简单问题更省时,复杂任务更稳。

    如何开始使用

    在线体验:Z.ai Chat 里选择 GLM-4.7
    API:Z.ai 文档提供接入指南(也支持通过 OpenRouter 使用)
    • 本地部署:权重已在 HuggingFace / ModelScope 提供,并支持 vLLM、SGLang 等推理框架
    • 编码代理:可在 Claude Code、Cline、Roo Code、Kilo Code 等工具中使用(订阅用户可按文中指引升级模型名为 glm-4.7

    原文链接:https://z.ai/blog/glm-4.7

    #GLM47 #AI编程 #Agent #工具调用 #推理能力
  5. Agent Skills:给 AI Agent “装上技能包”

    Agent Skills 是一种开放格式:把一套可复用的指令、脚本与资源打包成「技能」,让智能体在需要时按需加载,从而更准确、更高效地完成真实工作。

    为什么需要它?

    • 智能体能力越来越强,但常缺少上下文与流程知识;技能把这些程序化经验与团队/组织知识变成可携带、可版本管理的包
    • 对作者:一次构建,多处部署,跨多种智能体产品复用
    • 对企业与团队:把组织最佳实践沉淀为可审计、可迭代的工作流

    它能带来什么?

    领域专长:把法律审阅、数据分析等专业流程封装成可复用指南
    新能力扩展:例如自动做演示文稿、搭建 MCP Server、分析数据集等
    可重复的工作流:多步骤任务标准化,稳定且可追踪
    互操作性:同一技能可在不同“支持技能”的工具/产品间通用

    生态与开放性
    该格式最初由 Anthropic 提出并以开放标准发布,已被多种 AI 开发工具与产品支持,并在 GitHub 上开放协作。

    上手入口

    • 了解技能是什么、格式规范、如何集成、示例技能与参考库(校验与生成 prompt XML)

    原链接:https://agentskills.io/home
    #AI代理 #开放标准 #工作流 #知识沉淀 #开发者工具 Agent Skills Overview - Agent Skills
  6. PostHog AI: 开发 AI 智能体一年后总结的 8 个教训

    PostHog 团队在开发其内置 AI 智能体 PostHog AI 的一年中,积累了丰富的实践经验。从一个简单的聊天原型到一个能处理复杂分析任务的智能助手,他们总结了以下 8 个核心教训:

    1. 模型升级是推土机
    AI 模型的持续进步是开发中最强大的变量。曾经复杂的问题,如多步推理和工具调用,随着模型能力的提升而变得简单。密切关注模型发展至关重要.

    2. 循环智能体优于固定工作流
    相较于图表式的固定工作流,单一的循环智能体(Agent)更为灵活和强大。它能在执行任务中自我纠正,避免了工作流中常见的上下文丢失问题.

    3. 单一循环胜过子智能体架构
    复杂的子智能体架构听起来很智能,但在实践中容易因层层抽象而丢失关键信息,导致性能下降。一个简单、扁平的 LLM 循环反而能涌现出惊人的能力.

    4. “待办事项”是超能力
    让 LLM 在每一步操作后都使用一个简单的 `todo_write` 工具来规划下一步,这种看似简单的机制能有效帮助模型在复杂任务中保持专注和连贯性.

    5. 上下文是关键
    用户输入往往是模糊的,AI 需要广泛的背景知识才能准确理解. PostHog AI 通过 `/init` 命令自动学习项目信息,为智能体提供核心上下文,从而显著提升任务成功率.

    6. 展示每一步,建立信任
    透明度是建立用户信任的基石. 与其隐藏过程,不如将智能体的思考、工具调用甚至失败的尝试全部展示给用户. 这比一个完美的“黑箱”更能赢得信赖.

    7. 警惕 AI 框架的陷阱
    在 AI 技术飞速发展的今天,LangChain 等高级框架可能会过早地锁定技术选型. 在生态系统稳定之前,坚持使用更底层的库可能是更明智的选择.

    8. 评估(Evals)并非全部
    自动化评估很有价值,但无法替代对真实用户行为的分析. 通过观察实际使用中的 LLM 轨迹 (Traces),团队能发现评估中无法覆盖的、更深刻的问题.

    总而言之,构建高效的 AI 智能体需要拥抱变化、简化架构、重视上下文和透明度,并始终立足于真实的用户场景.

    原文链接: PostHog Blog

    #AI #Agent #LLM #工程实践 #PostHog 8 learnings from 1 year of agents – PostHog AI - PostHog
  7. 如何构建一个可靠的 AI Agent?

    随着 AI 的发展,构建能长期稳定运行且行为可靠的 Agent 已成为 AI 工程师的核心竞争力之一。借鉴 Anthropic、GitHub 和 Docker 的最新实践,我们可以遵循以下五个关键步骤来打造强大的 AI Agent。

    1. 从明确的规范开始
    当前多数 Agent 因指令模糊、状态和工作流管理不善而表现不佳。一份好的规范应明确其角色技术栈预期输出示例行为边界(如数据访问权限、API 速率限制等)。不要只依赖“你是一个有用的助手”,而是给 Agent 一份定义清晰的合同。

    2. 将工作分解为可验证的小任务
    与其给出一个模糊的大任务(例如“为我构建一个 X 的克隆”),不如将其分解为具体、可验证的步骤,如“计划 → 编码 → 测试 → 部署 → 监控”。为 Agent 提供清晰的任务列表和严格的工作流程,能有效避免因模糊性导致的失败。

    3. 在模型外部持久化状态
    为了让 Agent 能够处理长时间运行的任务并在会话中断后恢复,需要将其状态(如进度日志、任务清单、文件差异等)存储在外部文件或数据库中。这确保了 Agent 能够随时检索到完成任务所需的相关上下文。

    4. 避免过度填充上下文窗口
    将所有信息塞进系统提示会导致响应缓慢和高昂的 Token 成本。更高效的策略是让 Agent 生成代码来调用外部工具或 API,然后仅将结果返回给模型。这种方法能显著节省 Token,使 Agent 响应更快、成本更低。

    5. 在沙箱中运行高风险操作
    如果 Agent 需要执行代码,必须将其置于沙箱环境中,并严格限制其可用的工具文件系统访问权限。为 Agent 设置明确的“护栏”,可以有效降低应用和服务器面临的风险。

    总而言之,一个成功的 Agent 由三部分组成:行为(清晰的规范)、状态(外部持久化)和护栏(安全限制)。

    原文链接: https://interviewready.io/blog/how-to-build-an-ai-agent-lessons-from-anthrophic-github-and-docker

    #AIAgent #AI开发 #最佳实践 #工程化 How to Build an AI Agent: Lessons from Anthrophic, Github and Docker
1px