Anthropic工程师教你怎么做AI Agent:不做全场景、保持简单,像Agent一样思考

文章转载自「INDIGO 科技加速站」

Anthropic 工程师 Barry Zhang 在 AI Engineer 工作坊上的一个分享 “如何构建有效的 Agent”,其中印象最深的一个观点:Don’t build agents for everything,反过来理解就是别做什么都能干的 Agent,那是我们大模型要干的事情😄

构建有效 Agent 的三大要点:

  1. 明智选择应用场景,并非所有任务都需要 Agent
  2. 找到合适的用例后,尽可能长时间地保持系统简单
  3. 在迭代过程中,尝试从 Agent 的视角思考,理解其局限并提供帮助

Barry 主要负责 Agentic System,演讲内容基于他和 Eric 合著的一篇博文,下面详细总结他们的核心观点,以及对 Agent 系统的演进和未来的思考。

Agent 系统的演进

  1. 简单功能(Simple Features): 起初是简单的任务,如摘要、分类、提取,这些在几年前看似神奇,现在已成为基础。
  2. 工作流(Workflows): 随着模型和产品成熟,开始编排多个模型调用,形成预定义的控制流,以牺牲成本和延迟换取更好性能。这被认为是 Agent 系统的前身。
  3. Agent: 当前阶段,模型能力更强,领域特定的 Agent 开始出现。与工作流不同,Agent 可以根据环境反馈自主决定行动路径,几乎独立运作。
  4. 未来(猜测): 可能是更通用的单一 Agent,或多 Agent 协作。趋势是赋予系统更多自主权,使其更强大有用,但也伴随着更高的成本、延迟和错误后果。


Founder Park 正在搭建开发者社群,邀请积极尝试、测试新模型、新技术的开发者、创业者们加入,请扫码详细填写你的产品/项目信息,通过审核后工作人员会拉你入群~
进群之后,你有机会得到:
  • 高浓度的主流模型(如 DeepSeek 等)开发交流;

  • 资源对接,与 API、云厂商、模型厂商直接交流反馈的机会;

  • 好用、有趣的产品/案例,Founder Park 会主动做宣传。


01 

并非所有场景都适合构建 Agent

 (Don’t build agents for everything)

Agent 主要用于扩展复杂且有价值的任务,它们成本高、延迟高,不应作为所有用例的直接升级。对于可以清晰映射决策树的任务,显式构建工作流(Workflow)更具成本效益和可控性。

何时构建 Agent 的检查清单:

  1. 任务复杂度 (Complexity):Agent 擅长处理模糊的问题空间。如果决策路径清晰,应优先选择工作流。
  2. 任务价值 (Value): Agent 的探索性行为会消耗大量 token,任务的价值必须能证明其成本。对于预算有限(如每任务 10 美分)或高容量(如客服)场景,工作流可能更合适。
  3. 关键能力的可行性 (Derisk Critical Capabilities): 需确保 Agent 在关键环节(如编码 Agent 的编写、调试、错误恢复能力)不存在严重瓶颈,否则会显著增加成本和延迟。如有瓶颈,应简化任务范围。
  4. 错误成本与发现难度 (Cost of Error & Error Discovery): 如果错误代价高昂且难以发现,就很难信任 Agent 自主行动。可以通过限制范围(如只读权限、增加人工干预)来缓解,但这也会限制其扩展性。

编码(Coding)是一个很好的 Agent 用例,因为它任务复杂(从设计文档到 PR)、价值高、现有模型(如 Claude)在许多环节表现良好,且结果易于验证(单元测试、CI)。


02 

保持简单 (Keep it simple)

Agent 的核心结构:

模型(Model)+ 工具(Tools)+ 循环(Loop)在一个环境(Environment)中运作。

三个关键组成部分:
1. 环境 (Environment): Agent 操作所在的系统。
2. 工具集 (Tools): Agent 采取行动和获取反馈的接口。
3. 系统提示 (System Prompt): 定义 Agent 的目标、约束和理想行为。

迭代方法:

优先构建和迭代这三个基本组件,能获得最高的投资回报率。避免一开始就过度复杂化,这会扼杀迭代速度。优化(如缓存轨迹、并行化工具调用、改进用户界面以增强信任)应在基本行为确定后再进行。

一致性:

尽管不同 Agent 应用(编码、搜索、计算机使用)在产品层面、范围和能力上看起来不同,但它们共享几乎相同的简单后端架构。


03 

像 Agent 一样思考

 (Think like your agents)

问题:
开发者常从自身角度出发,难以理解 Agent 为何会犯看似反常的错误。

解决方法:
将自己置于 Agent 的“上下文窗口”中。Agent 在每一步的决策都基于有限的上下文信息(如 10k-20k token)。

换位思考练习:
尝试从 Agent 的视角完成任务,体验其局限性(例如,只能看到静态截图,在推理和工具执行期间如同“闭眼”操作)。这有助于发现 Agent 真正需要哪些信息(如屏幕分辨率、推荐操作、限制条件)以避免不必要的探索。

利用模型自身:
可以直接询问模型(如 Claude):指令是否模糊?是否理解工具描述?为什么做出某个决策?如何帮助它做出更好的决策?这有助于弥合开发者与 Agent 之间的理解差距。


04 

个人思考与未来展望

1. 预算感知 Agent (Budget-aware Agents):

需要更好地控制 Agent 的成本和延迟,定义和强制执行时间、金钱、token 预算,以便在生产环境中更广泛地部署。

2. 自进化工具 (Self-evolving Tools):

Agent 或许能设计和改进自己的工具(元工具),使其更具通用性,能适应不同用例的需求。

3. 多 Agent 协作 (Multi-agent Collaboration):

预计今年年底将在生产中看到更多多 Agent 系统。其优势包括并行化、关注点分离、保护主 Agent 上下文窗口等。关键挑战在于 Agent 间的通信方式,如何实现异步通信,超越当前的用户-助手轮流模式。

引用链接:

[1] How We Built Effective Agents: Barry Zhang, Anthropic: https://youtu.be/D7_ipDqhtwk?si=atqYQAuvl0xWwrcH


图片

(文:Founder Park)

欢迎分享

发表评论