如果翻阅今年2025年AI工程师峰会（纽约站）的演讲记录，你会发现一场极具实践价值的分享。Anthropic应用AI团队的核心成员Barry，这位曾在Meta自称首位“AI工程师”的技术领军人物，带着他的演讲《打造高效能AI Agent》登上了舞台。

这场分享没有空谈理论，也没有华丽的演示，更像是一份从一线实战中提炼出的操作指南。当“AI Agent”这一概念被反复炒作、无数团队蜂拥而至时，Barry的分享如同一盆冷水，浇醒了那些不切实际的幻想。他基于团队在企业服务与创业合作中积累的丰富经验，总结出三条核心原则，并对AI Agent的未来走向做出了极具价值的预判。

接下来，我们将深入解析这场分享的干货内容。

溯源探本：AI应用是如何演进到Agent阶段的？

在讨论“如何构建”之前，Barry先带大家回顾了AI应用的演进路径。这段回顾帮助我们理解了Agent的来龙去脉，也为后续观点奠定了坚实基础。

第一阶段：单点能力的魔法。大约两三年以前，我们还在为AI的“单点魔法”感到惊叹——文本摘要、情感分析、信息抽取，一次模型调用就能完成。如今，这些能力已成为AI应用的基本配置。

第二阶段：精心编排的工作流。随着需求日趋复杂，单一的模型调用显然力不从心。于是，我们步入了“工作流”时代。开发者像导演一样，将多个模型调用串联起来，设计出预定义的控制流程。这是一种平衡——用成本与延迟换取更稳定、更卓越的任务表现。Barry特别强调：工作流是通向Agent系统的必经之路，也是当下能够稳定交付商业价值的高效模式。

第三阶段：自主决策的智能体。如今，我们正处于Agent系统崭露头角的时期。与工作流最大的区别在于，Agent具备自主决策能力。它不再沿着预设路径行动，而是根据环境实时反馈，动态规划行动路线，几乎可以独立完成任务。这是我们今天讨论的焦点。

未来阶段：多智能体协作。展望未来，单一通用Agent会越来越强大，但另一个更值得期待的方向是多智能体系统的协作与任务分配——不同职能的Agent各司其职，协同作战。

Barry指出，这条演进路径揭示了一个核心趋势：随着我们赋予系统越来越高的自主性，其能力与实用性也在增强，但成本、延迟以及犯错带来的后果，同样急剧上升。

这一洞察，直接引出了他分享中最反直觉的第一条法则。

法则一：精准选择，并非所有任务都适合构建Agent

“不要为所有事情构建Agent。”Barry开门见山。

为什么？因为Agent并非解决所有问题的“万能钥匙”。它是规模化处理复杂且高价值任务的强大工具，但不该被滥用。如果能用更简单、更可控的工作流解决问题，那就别“杀鸡用牛刀”。

那么，什么时候才应该考虑构建一个Agent？Barry与他的团队总结出一份评估清单，我们称之为“四点清单”：

1. 任务复杂度。Agent真正发挥价值的地方在于高度模糊且不确定的问题空间。如果任务路径非常清晰，能轻松画出完整的决策树，那么最佳选择就是直接构建这个决策树，并对每个节点独立优化。这样成本效益更高，控制力也更强。反之，如果目标明确但路径充满变数（例如从产品设计文档到代码合并请求），这才是Agent应该上场的战场。

2. 任务价值。Agent的探索过程会消耗大量tokens，成本不菲。任务本身的价值必须能够支撑其运行成本。Barry举了一个例子：假设你正在构建一个高并发的客户支持系统，单次任务预算只有10美分，大概只够模型处理3到5万个tokens。这种情况下，最明智的做法是构建一个工作流，专门处理最常见的客户问题，以极低成本捕获绝大部分价值。

（Barry开了一个玩笑：“反过来讲，如果你评估任务价值时第一反应是‘我不在乎花多少tokens，我只想把事办成’，那请会后联系我，我们的商务团队非常乐意与您交流。”——这恰恰点明了高价值是Agent应用的核心前提。）

3. 关键能力风险评估。正式投入构建之前，必须先验证模型是否具备完成任务的核心能力，确保Agent的行动路径上没有致命的“瓶颈”。比如，要构建编码Agent，得先确认它是否擅长编写高质量代码、是否具备调试能力、能否从错误中恢复。如果存在明显短板，虽然不至于“胎死腹中”，但这些瓶颈会成倍增加成本与延迟。遇到这种情况，通常的建议是：缩小任务范围，简化问题，然后重试。

4. 错误成本与发现难度。最后，也是最关键的：评估Agent犯错的代价以及发现错误的难度。如果错误是高风险的，又难以被检测，那么你就很难信任Agent去自主执行操作。例如，一个操作生产数据库的Agent，一旦出错可能导致灾难性后果。你可以通过“只读权限”、“人类在环审核”来缓解风险，但这会极大限制Agent的自主性与规模化能力。

案例分析：为什么编码是Agent的绝佳应用场景？

Barry用“编码”这个场景完美串联了这四点：

• 复杂度：从设计文档到PR，路径极为复杂且模糊。
• 价值：高质量的代码对任何科技公司都价值连城。
• 能力：日常使用（比如用Claude写代码）已经验证了模型在编码各环节的强大能力。
• 错误成本：编码任务有一个得天独厚的优势——产出物极易验证。通过单元测试、集成测试和CI/CD流水线，可以快速、低成本地验证Agent生成代码的正确性。

正因为完美符合这四个标准，我们才看到了如今这么多富有创造力且成功的编码Agent。

法则二：极简至上，从最简可行Agent开始

当你通过了上述清单的考验，确定要构建一个Agent后，Barry给出的第二条法则是：尽可能保持简单。

在他看来，Agent的本质可以极度简化为一个核心循环：模型在一个循环中不断地使用工具。

在这个极简框架下，一个Agent的形态由三个基本组件组成：

• 操作环境：Agent赖以工作的系统，可以是代码库、浏览器、API集合，甚至整个操作系统。
• 工具集：为Agent提供的行动接口，例如readFile、writeFile、runTerminalCommand。
• 系统提示词：Agent的大脑与灵魂，定义了它的目标、行为准则和思考方式。

“我们以惨痛的教训认识到，任何前期的过度设计都会扼杀迭代速度。”Barry说得非常直接。把精力集中在这三个基本组件的打磨上，能带来最高的回报率。所有复杂的优化都应该在基本行为调校好之后再考虑。

他展示了团队内部构建的三个截然不同的Agent案例：编码Agent、搜索Agent、桌面操作Agent。它们产品形态、任务范围和能力千差万别，但令人惊讶的是，它们的底层代码和核心架构几乎完全相同，都遵循着“模型+工具+提示词”的极简范式。

环境由用例决定，对AI工程师来说，最初的设计决策只有两个：

• 提供什么样的工具集？
• 撰写什么样的系统提示词？

一旦这个最简可行Agent能跑起来，就可以考虑各种优化了。例如：

• 对编码Agent，缓存行动轨迹以降低重复任务的成本。
• 对搜索Agent，由于涉及大量工具调用，并行化这些调用来缩短延迟。
• 对所有Agent，设计一个能清晰展示其思考过程和进度的用户界面，对建立信任至关重要。

先让Agent跑起来，观察它的行为，然后再进行针对性优化。先求生存，再求发展。

法则三：换位思考，以Agent视角看世界

这是Barry分享中最具启发性的部分：“像你的Agent一样思考。”

许多开发者（包括他自己）在开发Agent时常常陷入一个误区：从自己的“上帝视角”出发，理所当然地认为Agent应该知道我们所知道的一切。因此，当Agent犯下一些在我们看来匪夷所思的错误时，我们会感到困惑和挫败。

Barry的建议是：把自己代入到Agent的上下文窗口中去。

Agent的行为可能看起来异常复杂和智能，但在每个决策瞬间，模型做的依然只是对一段极其有限的上下文进行推理。它对当前世界状态的全部认知，都来自于那几千或几万个tokens的上下文。

一个沉浸式体验：假设你是一个桌面操作Agent。

为了让我们切身感受这一点，Barry设计了一个思想实验。想象一下，你现在是一个桌面操作Agent。你得到的全部信息是：

• 一张静态的屏幕截图。
• 一段由“不靠谱的”人类（也就是你自己）写的、极其简陋的任务描述。

你的系统提示词告诉你，你有一些工具（比如click(x, y)），你的任务是完成某个操作。“你可以尽情地思考、推理、规划，但唯一能对环境产生影响的，只有你手中的工具。”

你决定尝试一次点击。当你调用click工具后，在模型推理和工具执行的那3到5秒内，世界对你来说是完全黑暗的。这相当于你闭上眼睛，在黑暗中盲目地操作电脑。

几秒后，你睁开眼，看到了一张全新的截图。你刚才的点击可能成功了，也可能点错了按钮，甚至可能已经把电脑关机了。你一无所知。这个结果反馈回来后，新一轮的循环又开始了。

“我强烈建议你们亲身尝试用这种方式完成一个完整的任务。我保证，这是一次既奇妙又略带不适的体验。”

一旦你经历了这种“略带不适”的体验，你就会立刻明白Agent真正需要什么。你会发现：在截图中提供屏幕分辨率信息是多么重要，否则click(x, y)的坐标毫无意义。在提示词中加入一些推荐操作或明确的限制，可以提供有效的护栏，避免Agent进行无谓的、高成本的探索。

终极技巧：让Claude来理解Claude。

幸运的是，我们正在构建的系统能听懂人话。所以，我们可以直接“盘问”它：

把你的系统提示词扔给模型，问它：“这段指令有模糊不清的地方吗？你理解起来费劲吗？”

把你的工具描述扔给模型，问它：“你知道怎么用这个工具吗？你是希望它的参数多一点还是少一点？”

最强大的用法是：把Agent犯错时的完整行动轨迹（包括它的思考过程和工具调用历史）全部扔给模型，然后问它：“嘿，你当时为什么会做出这个决定？我需要提供什么额外的信息，才能帮助你在未来做出更好的决策？”

这种方法不能完全替代你自己的理解，但能帮你快速拉近你和Agent之间的认知差距，真正从它的视角看世界。

未来展望：AI工程师需要共同解决的三大开放性问题

在分享的最后，Barry谈到了他对Agent未来发展的思考，以及整个AI工程社区需要共同努力解决的三个开放性问题。

1. 成本感知型Agent。与路径确定的工作流不同，我们目前对Agent的成本和延迟缺乏有效的控制手段。如何让Agent具备“成本意识”，能根据设定的成本、时间或tokens限制来智能调整策略？解决这个问题，将为更多对成本敏感的业务场景解锁Agent的应用，是其走向大规模生产部署的关键。

2. 自进化工具。我们已经在使用模型来迭代和优化工具描述，但这个想法可以被泛化得更远。未来，Agent或许可以拥有一个“元工具”，让它能根据具体任务自主地设计、组合甚至改进自己的工具集。这将极大提升Agent的通用性和适应性，让它们为每个用例“量身定制”最高效的工具。这被称作工具的人体工程学。

3. 多智能体协作。“从趋势来看，到今年年底，我们将在生产环境中看到越来越多的多智能体协作案例。” Barry对此毫不怀疑。多智能体系统具有天然优势：易于并行化、关注点分离清晰（比如让一个子Agent专门负责文件操作，可以保护主Agent宝贵的上下文窗口）。但这里最大的开放性问题是：这些Agent之间应该如何沟通？我们目前深陷于“用户-助手”式的同步、回合制对话框架中。如何打破这个框架，设计出支持异步通信、支持不同角色（如管理者、执行者、审查者）的交互协议，将是引爆多智能体未来的关键。

结语：让我们持续构建

Barry的分享以一个个人故事收尾。2023年，在Meta的他读了Swyx的博客文章后深受启发，将自己的职位描述改成了公司第一位“AI工程师”。他热爱这种专注于实用性、致力于让AI为世界创造真实价值的理念。正是这份初心，将他带到了今天的舞台上。

回顾整场分享，Barry没有兜售高深的理论，也没有展示华而不实的演示。他带来的三条法则，朴素但直击要害：

• 精挑细选：别为所有事情构建Agent，用“四点清单”找到真正适合的场景。
• 大道至简：从“模型+工具+提示词”的最简可行Agent开始，快速迭代。
• 换位思考：跳出人类的上帝视角，代入Agent的有限上下文，理解它的世界。

在AI Agent的浪潮之下，这份来自一线的真知灼见，无疑为所有AI工程师指明了一条更清晰、更务实的航道。

“Let's keep building.” 让我们持续构建。