Agent系统的构建绝非简单的技术堆砌，而是需要精准的场景匹配与能力设计。Anthropic工程师Barry Zhang深度揭秘了Agent与Workflow的本质区别，并提出了判断任务是否适合Agent化的三大标准——复杂度、价值与关键能力。从编程Agent的实践案例到‘闭眼操作电脑’的生动比喻，这场演讲为AI产品经理提供了构建有效Agent的全新思考框架。
今天分享Anthropic团队的工程师Barry Zhang在AI Engineer Summit上的演讲：How We Build Effective Agents。
Barry Zhang在 Anthropic Applied AI 团队负责和企业、创业公司一起开发 Agent 系统。
他分享的核心内容不是要不要做 Agent，而是：
什么事情适合交给 Agent，Agent 应该怎么做，怎么让它掌握真正的专业能力。
Barry Zhang 先回顾了过去两三年大家做 AI 产品的路径。
一开始，大多数人做的是很简单的功能。
比如总结、分类、信息提取。这些事情在两三年前还很像魔法。
你把一段文本丢进去，模型帮你总结重点；你把一批内容丢进去，模型帮你分类；你把一份材料丢进去，模型帮你抽取关键信息。
但到了今天，这些能力已经变成基础能力。
它们仍然有用，但已经不是最前沿的东西。
后来，产品变复杂了，大家开始发现，一个模型调用不够用了。
有些任务需要多个步骤。
一个模型先做提取，另一个模型再做判断；一个模型先生成大纲，另一个模型再根据大纲写文档；一个模型先识别用户问题，再把问题分发到不同处理流程。
于是，大家开始把多个模型调用放进一个预先设定好的流程里。
这种方式叫做workflow，也就是工作流。
工作流的特点是：路线是人提前设计好的。
每一步做什么，下一步走哪里，什么情况下进入哪个分支，基本都由开发者提前安排好。
这已经是 Agent 系统的起点。
因为它不再只是一次模型调用，而是多个模型调用和工具调用的组合。
后来，模型能力继续变强，真正的 Agent 开始出现。
Anthropic 对 workflow 和 Agent 做了一个很清楚的区分：
Workflow 是大模型和工具按照预先设计好的流程运行；
Agent 则是大模型可以根据环境反馈，自己决定下一步怎么走。
也就是说，workflow 更像一条固定生产线；Agent 更像一个能自己判断路线的执行者。
它可以观察环境，调用工具，看到反馈，再决定下一步行动。
这也是 Agent 更有价值的地方。
但 Barry 同时提醒，Agent 自主性越强，问题也越多。
它会更有用，更有能力，但成本、延迟、错误后果也会一起上升。
这个判断很重要。
现在很多人一谈 Agent，就很容易把它当成一个默认升级方向。
好像只要把一个 AI 功能做成 Agent，它就更先进。
Anthropic 的判断刚好相反：
Agent 应该用来处理复杂、有价值、值得探索的任务。它不应该成为每个场景的默认升级包。
Barry 给了一个很实用的判断标准。
第一，看任务复杂度。
Agent 更适合模糊、开放、难以提前穷尽路径的问题。
如果一个任务的决策树很容易画出来，每一步怎么走都很清楚，那就没有必要上 Agent。
直接把流程写出来，把每个节点优化好，成本更低，也更可控。
比如一个简单客服问题：用户问退款政策，系统查订单、判断是否符合条件、给出回复。
这类任务如果路径非常清楚，用工作流就够了。
第二，看任务价值。
Agent 的探索过程会消耗很多 token。
token 可以简单理解成模型处理文本和任务的基本单位，也直接影响调用成本。
Barry 举了一个很具体的例子：
如果你做的是高频客服系统，每次任务预算大概只有 10 美分，那大概只能支撑 3 万到 5 万 token。
在这种情况下，最好用工作流覆盖最常见的问题。
这样已经能拿到大部分价值。
但如果你看到这个问题的第一反应是：token 花多少都没关系，我只要把任务做完。
Barry 开玩笑说，那 Anthropic 的商业团队很愿意和你聊聊。
这句话背后的意思很直接：Agent 不是便宜方案。
它适合那些结果足够有价值、过程足够复杂、成本可以被任务价值覆盖的场景。
第三个判断标准，是关键能力有没有风险。
如果你要做一个编程 Agent，就要先确认它能不能写出好代码，能不能调试，能不能从错误中恢复。
如果中间有明显瓶颈，这不一定让项目失败，但会不断放大成本和延迟。
这时候 Anthropic 通常会做一件事：缩小范围，简化任务，再试一次。
最后一个判断标准，是错误成本和错误发现难度。
如果一个任务出错代价很高，而且错误很难被发现，那就很难放心让 Agent 自主行动。
当然，可以通过限制权限来降低风险。
比如只给它只读权限，或者在关键节点加入人工确认。
但这样做也会限制 Agent 的扩展能力。
Agent 的价值来自自主性，自主性越强，能扩展的空间越大。
但风险也越高。
所以真正的问题不是能不能做 Agent，而是这个任务的风险和收益是否匹配。
Barry 用编程举了一个例子。为什么现在会看到这么多编程 Agent？
因为写代码刚好符合这些条件。
从一份设计文档到一个 PR，本来就是一个复杂、模糊、开放的任务。
程序员改完代码后，一般会提交 PR，让系统或团队成员检查代码变更，再决定是否合并进主代码库。
从设计文档到 PR，中间要理解需求、读代码、改文件、跑测试、修错误、再提交结果。
这不是一个简单线性流程。
第二，好代码本身很有价值。
工程师时间贵，代码质量也直接影响产品。
第三，Claude 在编程流程里的多个环节已经表现不错。
第四，代码有一个很重要的特性：结果容易验证。
它可以通过单元测试和 CI 来检查。代码能不能跑，测试能不能过，报错在哪里，都有比较清楚的反馈。
这也是编程 Agent 很容易跑起来的原因。
它不只是任务复杂、价值高，更重要的是结果可以被验证。
找到适合 Agent 的任务之后，Anthropic 的第二条建议是：保持简单。
Barry 说，在他们看来，Agent 的样子很简单：模型在一个循环里使用工具。
更具体一点，一个 Agent 由三个部分组成。
第一，环境。
也就是 Agent 正在操作的系统。它可能是代码库，可能是网页，可能是企业内部软件，可能是一个文件系统。
第二，工具。
工具给 Agent 提供行动接口，让它可以真正改变环境，并获得反馈。比如搜索、读文件、写文件、运行代码、调用接口、点击网页。
第三，系统提示词。
系统提示词告诉 Agent 目标、约束和理想行为。它要做什么，不能做什么，应该用什么方式做，都在这里定义。
然后，模型在这个结构里不断被调用，形成一个循环 loop。
这就是 Agent。
Barry 说，他们是用很痛的方式学到这件事的：一开始加太多复杂设计，会严重拖慢迭代速度。
真正高回报的事情，是先把环境、工具和系统提示词这三个基本组件做好。
优化可以放在后面。
比如编程和电脑操作场景里，可以缓存 Agent 的执行轨迹来降低成本。
搜索场景里，如果工具调用很多，可以并行执行来降低延迟。
几乎所有场景里，都要把 Agent 的进度清楚展示给用户，让用户能建立信任。
但这些都应该在基本行为跑通之后再做。
先让 Agent 真的能干活，再优化速度、成本和体验。
第三条建议，是像 Agent 一样思考。
这句话听起来有点抽象，但 Barry 讲得很清楚：很多开发者会从自己的视角开发 Agent。
然后，当 Agent 犯一个看起来很低级的错误时，就会觉得困惑：为什么它连这个都不懂？
Barry 说，这时候要把自己放进 Agent 的上下文窗口里。
上下文窗口，可以理解成模型当前能看到、能记住、能用来推理的那部分信息。
Agent 看起来可以做很复杂的事情，但在每一步，它本质上仍然是在一段有限上下文里做推理。
Barry 提到，模型对当前世界的理解，可能就压在 1 万到 2 万 token 里。
所以你要问的问题不是：这个任务对人类来说是不是很简单？
而是：我给 Agent 的上下文，真的足够吗？
信息是不是清楚？
它看到的世界是不是连贯？
它知道下一步能做什么吗？
Barry 举了一个很有画面感的例子：假设你现在就是一个电脑操作 Agent。
你能看到什么？
你不是像人一样坐在电脑前，持续看到整个屏幕变化。
你拿到的，可能只是一张静态截图，再加上一段写得很差的描述。
你可以思考、推理、说很多话。
但真正能改变环境的，只有工具调用。
你尝试点击一下。
在模型推理和工具执行的几秒钟里，你其实看不见发生了什么。
这相当于你闭上眼睛三到五秒，在黑暗里操作电脑。
然后你睁开眼睛，看到下一张截图。
刚刚那一下可能成功了，也可能把电脑关了。
你不知道。
你只能从新的截图里继续判断。
Barry 说，建议开发者真的从 Agent 的视角完整做一次任务。
这个体验会很有意思，也会有一点不舒服。
但做完之后，你会立刻明白 Agent 到底缺什么。
比如，它需要知道屏幕分辨率，这样才知道怎么点击。
它需要知道推荐动作和限制条件，这样才不会做太多无效探索。
它需要一些护栏，知道哪些地方不要碰，哪些操作需要谨慎。
这就是“像 Agent 一样思考”的意思。
不是把人的常识强行塞给 Agent，而是看清楚它每一步到底拿到了什么信息，又能采取什么行动。
Barry 还提到一个很实用的方法：
因为我们正在构建的是会说自然语言的系统，所以可以直接让 Claude 帮你理解 Claude。
比如，你可以把系统提示词丢给 Claude，问它：
这段指令有没有歧义？
你能不能按这个要求执行？
你会在哪里困惑？
你也可以把工具说明丢给它，问它：
你知道这个工具该怎么用吗？
你需要更多参数，还是更少参数？
哪些描述不清楚？
他们还经常把 Agent 的完整执行轨迹丢给 Claude，然后问：
为什么你会在这里做这个决定？
有什么信息可以帮助你做得更好？
这不能替代开发者自己理解上下文，但可以帮助开发者更接近 Agent 的视角。
很多时候，Agent 出错不是因为模型“笨”，而是它看到的世界本来就不完整。
Barry 在演讲最后分享了三个他一直在思考的问题。
第一个，是让 Agent 更有预算意识。
Workflow 的成本和延迟比较容易控制。
因为流程是固定的，每一步调用什么、调用几次，大概可以预估。
但 Agent 不一样，它会探索，会尝试，会走弯路，也可能反复调用工具。
所以今天我们还没有很好地控制 Agent 的时间、成本和 token 预算。
Barry 认为，如果能更好地定义和执行这些预算，很多 Agent 场景就会更容易进入生产环境。
第二个，是自我演化的工具。
现在他们已经在用模型帮助改进工具说明，但未来这件事可以更进一步。
Agent 可以设计和改进自己的工具，让工具更适合当前任务。
也就是说，不只是人给 Agent 工具，Agent 也可以让工具变得更好用。
第三个，是多 Agent 协作。
Barry 认为，生产环境里会看到更多多 Agent 协作。
原因也很清楚：多 Agent 可以很好地并行工作，以及不同 Agent 可以分工明确。
子 Agent 还能保护主 Agent 的上下文窗口，不让主任务被太多细节挤占。
但这里还有一个关键问题：Agent 之间到底怎么沟通？
现在很多系统还是围绕“用户—助手”这种同步对话结构搭起来的。
未来如果要支持多个 Agent 异步协作，就需要新的通信方式、新的角色设计，以及让 Agent 彼此识别和配合的机制。
这会是下一阶段很重要的问题。
以上，祝你今天开心。
作者：张艾拉 公众号：Fun AI Everyday
本文由 @张艾拉 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自作者提供
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。