在今年AI Engineer Summit 2025纽约峰会上，一股关于“如何务实构建AI系统”的清风席卷全场。Anthropic应用AI团队的技术核心成员Barry，这位曾在Meta自封为首位“AI工程师”的技术大牛，带来了一场名为《构建高效能Agent》的精彩分享。
这不仅仅是一场技术演讲，更像是一份来自一线战场的实战手册。在Agent概念被热炒，无数团队涌入这条赛道的今天，Barry的分享如同一剂清醒剂，剥离了浮夸的想象，直指构建稳健、可靠、有价值的Agent系统的核心。他基于团队在企业服务和创业合作中积累的大量经验，提出了三大黄金法则，并对Agent的未来演进提出了深刻的洞见。
这篇文章将带你深度解读Barry的分享，内容详实，建议收藏。
正本清源：我们是如何走到Agent这一步的？
在深入探讨“如何构建”之前，Barry首先带领我们回顾了AI应用演进的清晰路径，这为我们理解Agent的定位提供了至关重要的上下文。
第一阶段：单点能力的魔法。大约在两三年前，我们还惊叹于AI的“单点魔法”。无论是文本摘要、情感分类还是信息提取，单个模型调用（One Model Call）就能完成的任务，在当时看来已是不可思议的创举。如今，这些能力已然成为AI应用的“标配”，是任何产品都无法绕过的基础功能。
第二阶段：精心编排的工作流。随着产品和需求的成熟，单一的模型调用显然已无法满足更复杂的任务。于是，我们进入了“工作流”时代。开发者们开始像导演一样，将多个模型调用串联起来，设计出预定义的控制流程（Predefined Control Flows）。这种方式本质上是一种权衡——我们通过牺牲一定的成本和延迟，来换取更稳定、更出色的任务表现。Barry强调，工作流是通向Agent系统的必经之路，也是当下能够稳定交付商业价值的强大模式。
第三阶段：自主决策的智能体。现在，我们正处在Agent系统崭露头角的时代。与工作流最大的不同在于，Agent拥有了自主决策的能力。它不再严格遵循预设的路径，而是可以根据环境的实时反馈，动态地规划自己的行动轨迹（Trajectory），几乎可以独立地完成任务。这是我们今天讨论的焦点。
未来阶段：多智能体协作展望未来。单一的通用Agent可能会变得越来越强大，但另一个更激动人心的方向是多智能体系统的协作与委派。不同职能的Agent各司其职，协同作战。
Barry指出，这条演进路径揭示了一个核心趋势：随着我们赋予系统越来越高的自主性（Agency），它的能力和实用性也随之增强。但与此同时，其成本、延迟以及犯错所带来的后果，也在急剧上升。
这个深刻的洞察，直接引出了他要分享的第一个，也是最反直觉的一个法则。
法则一：有所为，有所不为——别为所有事情构建Agent
“Don't build agents for everything.” Barry开宗明义。
为什么不呢？因为Agent并非解决一切问题的“银弹”。它是一种用于规模化解决复杂且高价值任务的强大工具，但不应该被滥用于所有场景。如果我们能用更简单、更可控的工作流解决问题，那就不应该“杀鸡用牛刀”。
那么，到底什么时候才应该考虑构建一个Agent？Barry和他的团队总结出了一份极其宝贵的四点评估清单：
1. 任务复杂度
Agent真正的用武之地在于高度模糊和不确定的问题空间。如果你的任务路径非常清晰，可以轻松地绘制出完整的决策树，那么最佳选择是明确地构建这个决策树，并对每个节点进行独立优化。这不仅成本效益更高，而且能让你拥有绝对的控制力。反之，如果任务的目标明确，但实现路径充满变数，需要不断探索和试错（比如从一份产品设计文档到一个完整的代码合并请求），这才是Agent大展拳脚的舞台。
2. 任务价值
Agent的探索过程会消耗大量的tokens，这意味着它“身价不菲”。因此，任务本身的价值必须能够支撑其高昂的运行成本。
Barry举了一个生动的例子：假设你在构建一个高并发的客户支持系统，单次任务的预算被严格控制在10美分左右。这点预算大概只够模型处理3到5万个tokens。在这种情况下，最明智的做法是构建一个工作流，专门处理那些最常见的客户问题，这样就能以极低的成本捕获绝大部分价值。
（ Barry在这里还开了一个玩笑：“反过来说，如果你在评估任务价值时，第一反应是‘我不在乎花多少tokens，我只想把事儿办成’，那么请在会后联系我，我们的商务团队非常乐意与您交流。” 这点明了高价值是Agent应用的核心前提。）
3. 关键能力风险评估
在正式投入构建Agent之前，必须先验证模型是否具备完成任务所需的核心能力，确保在Agent的行动路径上没有致命的“瓶颈”。
例如，要构建一个编码Agent，你得先确认它是否擅长编写高质量代码、是否具备调试能力、以及是否能从错误中有效恢复。如果存在明显的短板，虽然不至于让项目“胎死腹中”，但这些瓶颈会成倍地增加你的成本和延迟。遇到这种情况，通常的建议是：缩小任务范围，简化问题，然后重试。
4. 错误成本与发现难度
最后，也是最关键的一点，你需要评估Agent犯错的代价以及发现错误的难度。如果错误是高风险的（High-stake），且难以被检测（Hard to discover），那么你将很难信任Agent去自主执行操作。
比如，一个操作生产数据库的Agent，一旦出错可能导致灾难性后果。你可以通过增加“只读权限”、“人类在环审核”等方式来缓解风险，但这同时也会极大地限制Agent的自主性和规模化能力。
案例分析：为什么编码是Agent的绝佳用例？
Barry用“编码”这个场景完美地串起了这四点：
复杂度：从设计文档到PR，路径极其复杂模糊。
价值：高质量的代码对任何科技公司都价值连城。
能力：我们已经通过日常使用（如用Claude写代码）验证了模型在编码各环节的强大能力。
错误成本：编码任务有一个得天独厚的优势——产出物极易验证。通过单元测试、集成测试和CI/CD流水线，我们可以快速、低成本地验证Agent生成代码的正确性。
正是因为完美符合这四个标准，我们才看到了如今这么多富有创造力且成功的编码Agent。
法则二：大道至简——从最简可行Agent开始
当你通过了上述清单的考验，确定要构建一个Agent后，Barry给出的第二个法则是：Keep it as simple as possible.
在他看来，Agent的本质可以被极度简化为一个核心循环：模型在一个循环中不断地使用工具。
在这个极简框架下，一个Agent的形态由三个基本组件定义：
环境：Agent赖以操作的系统。它可以是一个代码库、一个浏览器、一个API集合，甚至是整个操作系统。
工具集：为Agent提供的行动接口。这些工具让Agent能够与环境互动并获得反馈，比如readFile、writeFile、runTerminalCommand等。
系统提示词：Agent的大脑和灵魂。它定义了Agent的目标、行为准则、约束条件以及它应该如何思考和行动。
“我们以惨痛的教训认识到，任何前期的过度设计都会扼杀迭代速度。” Barry语重心长地说道。他强调，把精力集中在这三个基本组件的打磨上，将带来最高的回报率（ROI）。所有复杂的优化都应该在基本行为（Behaviors）调校好之后再进行。
他展示了团队内部构建的三个看似截然不同的Agent案例：一个编码Agent、一个搜索Agent和一个桌面操作Agent。它们在产品形态、任务范围和能力上千差万别，但令人惊讶的是，它们的底层代码和核心架构几乎完全相同，都遵循着上述的“模型+工具+提示词”的极简范式。
环境由用例决定，因此，对于AI工程师而言，最初的设计决策只有两个：
提供什么样的工具集？
撰写什么样的系统提示词？
一旦这个最简可行Agent能够运转起来，你就可以开始考虑各种优化了。比如：
对编码Agent，可以缓存其行动轨迹，以降低重复任务的成本。
对搜索Agent，由于涉及大量工具调用，可以并行化这些调用来缩短延迟。
对所有Agent，设计一个能够清晰展示其思考过程和进度的用户界面，对于建立用户信任至关重要。
总而言之，先让Agent跑起来，观察它的行为，然后再进行针对性的优化。先求生存，再求发展。
法则三：像Agent一样思考——跳出“人类上帝视角”
这是Barry分享中最具启发性的一点：“Think like your agents.”
许多开发者（包括他自己）在开发Agent时，常常会陷入一个误区：我们从自己的“上帝视角”出发，理所当然地认为Agent应该知道我们所知道的一切。因此，当Agent犯下一些在我们看来匪夷所思的错误时，我们会感到困惑和挫败。
Barry的建议是：把自己代入到Agent的上下文窗口（Context Window）中去。
Agent的行为可能看起来异常复杂和智能，但在每一个决策瞬间，模型所做的依然只是对一段极其有限的上下文进行推理。它对当前世界状态的全部认知，都来自于那几千或几万个tokens的上下文。
一个沉浸式体验：假如你是一个桌面操作Agent
为了让我们切身感受这一点，Barry设计了一个思想实验： 想象一下，你现在是一个桌面操作Agent。你得到的全部信息是：
一张静态的屏幕截图。
一段由“不靠谱的”人类（也就是你自己）写的、极其简陋的任务描述。
你的系统提示词告诉你，你有一些工具（比如click(x, y)），你的任务是完成某个操作。“你可以尽情地思考、推理、规划，但唯一能对环境产生影响的，只有你手中的工具。”
你决定尝试一次点击。当你调用click工具后，在模型推理和工具执行的那3到5秒内，世界对你来说是完全黑暗的。这相当于你闭上眼睛，在黑暗中盲目地操作电脑。
几秒后，你睁开眼，看到了一张全新的截图。你刚才的点击可能成功了，也可能点错了按钮，甚至可能已经把电脑关机了。你一无所知。这个结果反馈回来后，新一轮的循环又开始了。
“我强烈建议你们亲身尝试用这种方式完成一个完整的任务。我保证，这是一次既奇妙又略带不适的体验。”
一旦你经历了这种“略带不 "适”的体验，你就会立刻明白Agent真正需要什么。你会发现：在截图中提供屏幕分辨率信息是多么重要，否则click(x, y)的坐标毫无意义。
在提示词中加入一些推荐操作或明确的限制，可以提供有效的护栏（Guardrails），避免Agent进行无谓的、高成本的探索。
终极技巧：让Claude来理解Claude
幸运的是，我们正在构建的系统能听懂人话。所以，我们可以直接“盘问”它：
把你的系统提示词扔给模型，问它：“这段指令有模糊不清的地方吗？你理解起来费劲吗？”
把你的工具描述扔给模型，问它：“你知道怎么用这个工具吗？你是希望它的参数多一点还是少一点？”
最强大的用法是：把Agent犯错时的完整行动轨迹（包括它的思考过程和工具调用历史）全部扔给模型，然后问它：“嘿，你当时为什么会做出这个决定？我需要提供什么额外的信息，才能帮助你在未来做出更好的决策？”
这种方法不能完全替代你自己的理解，但它能帮你快速拉近你和Agent之间的认知差距，真正从它的视角看世界。
未来展望：AI工程师需要共同解决的三大开放性问题
在分享的最后，Barry分享了他个人对Agent未来发展的一些思考，以及他认为整个AI工程社区需要共同努力解决的三个开放性问题。
1. 预算感知型Agent
与路径确定的工作流不同，我们目前对Agent的成本和延迟缺乏有效的控制手段。如何让Agent具备“预算意识”，能够根据设定的成本（金钱）、时间或tokens限制来智能地调整自己的策略？解决这个问题，将为更多对成本敏感的业务场景解锁Agent的应用，是其走向大规模生产部署的关键。
2. 自进化工具
我们已经在使用模型来帮助我们迭代和优化工具描述，但这个想法可以被泛化得更远。未来，Agent或许可以拥有一个“元工具”（Meta-Tool），让它能够根据具体任务，自主地设计、组合甚至改进自己的工具集。这将极大地提升Agent的通用性和适应性，让它们能够为每个用例“量身定制”最高效的工具。我们称之为工具的人体工程学。
3. 多智能体协作
“我个人坚信，到今年年底，我们将在生产环境中看到越来越多的多智能体协作案例。” Barry对此毫不怀疑。多智能体系统具有天然的优势：易于并行化、关注点分离清晰（比如让一个子Agent专门负责文件操作，可以保护主Agent宝贵的上下文窗口）。
但这里最大的开放性问题是：这些Agent之间应该如何沟通？
我们目前深陷于“用户-助手”式的同步、回合制对话框架中。如何打破这个框架，设计出支持异步通信、支持不同角色（如管理者、执行者、审查者）的交互协议，将是引爆多智能体未来的关键。
结语：让我们持续构建
Barry的分享以一个个人故事收尾。2023年，在Meta的他读了Swyx的博客文章后深受启发，将自己的职位描述改成了公司第一位“AI工程师”。他热爱这种专注于实用性、致力于让AI为世界创造真实价值的理念。正是这份初心，将他带到了今天的舞台上。
回顾整场分享，Barry没有兜售高深莫测的理论，也没有展示华而不实的Demo。他带来的是三条朴素却直击要害的法则：
精挑细选：别为所有事情构建Agent，用“四点清单”找到真正适合的场景。
大道至简：从“模型+工具+提示词”的最简可行Agent开始，快速迭代。
换位思考：跳出人类的上帝视角，代入Agent的有限上下文，理解它的世界。
在AI Agent的浪潮之下，这份来自一线的真知灼见，无疑为所有AI工程师指明了一条更清晰、更务实的航道。
“Let's keep building.” 让我们持续构建。
