从回答到行动的转变
过去几年里，我们中的大多数人都以一种方式看待语言模型：就像我们对一个读书很充分、非常有见识的同事那样。你问一个问题，就得到一个答案，而接下来发生什么取决于你。这种工作方式正悄悄地被替换掉了。如今有趣的问题不再是如何让模型说出正确的话。他们在于让一个系统做正确的事——贯穿许多步骤，借助真实工具，在混乱的环境中运行；而在这些环境里，最初的计划很少能与现实相吻合。
这就是“智能体工程”（agentic engineering）所要讨论的内容。它是一门学科：去设计、构建并运行这样的系统——当模型不只是产出文本，而是采取行动、查看结果，并在目标达成前不断决定下一步做什么。模型依然处在核心位置，但它现在只是更大机器中的一个组件；而真正的大部分难点，存在于它周围的一切事物之中。
这种转变之所以重要，是因为技能不同。提示词写作奖励的是巧妙的措辞。智能体工程奖励的是那些一直让软件可靠的东西：清晰的接口、良好的可观测性、对失败的合理处理，以及“你交付了什么、你学到了什么”之间紧密的闭环。唯一真正新加入的成分，是那个不可预测地坐在这一切中间的因素。
智能体究竟是什么
“智能体”（agent）这个词被泛化到几乎可以覆盖任何东西，因此有必要说得精确一些。智能体是一个系统：它会通过反复选择行动来追求目标；这些行动基于它所观察到的内容，而不是遵循固定脚本。其决定性特征是循环，而不是智能。恒温器遵循一条规则。智能体会做决定。
把自主性视为一条光谱，而不是“是或否”，会有帮助。在一端是一次单独的模型调用，用来对邮件进行分类。再往前一点，工作流会把多次调用以固定顺序串联起来，这很有用，但仍然是脚本式的。更进一步，模型会选择何时调用哪个工具，并持续进行，直到它判断工作已完成。到了最远的端点，系统会设定自己的子目标、管理自己的记忆，并能运行数小时。如今大多数生产系统都落在中间某处，而这通常是正确的位置，因为真正的完全自主很少是问题本身所真正需要的。
尽早弄清楚你的系统在这条光谱上的位置，是你能做的最能澄清一切的事情之一。它告诉你，你可以在多大程度上依赖模型的判断，需要施加多少结构，以及风险会集中在哪里。
智能体循环
撇开各种框架名称和营销话术，几乎每个智能体都会运行相同的循环。它会收集关于自身处境的上下文，对该做什么进行推理，采取一个行动，并观察结果是什么。然后它会再绕一圈，使用刚刚学到的东西——直到达到目标或放弃。
这个循环中的每一次经过，都是一个决策点；而决策点正是事情做对或做错的地方。一个好的智能体循环，不是提示词最巧妙的那个。它是每个阶段都恰好拥有足够的信息来做出正确选择，而不多也不少。把模型需要看到的所有事情的完整历史都给它，它就会断了线索。给得太少，它就会像盲人一样行动。许多“手艺”的关键在于：每一轮让模型看见什么。
这个循环也解释了为什么构建智能体会让人感觉与普通软件如此不同。在正常代码里，你可以推理每一条路径。而在这里，模型可以选择一条你从未想过的路径，从一种你并未计划的方式里恢复错误，或者在看起来合理的方向上走三步后突然崩塌。你并不是在“编写路径”。你是在塑造可能路径的空间，并努力让好的路径更容易被找到。
智能体的解剖结构
把智能体想象成一小组零件，每个零件各做一件事，会有帮助。有模型，它提供推理和语言。有工具，它让系统能对现实世界采取行动，并从中读取反馈。有记忆与上下文，它们把相关信息带入每一次决策。还有围绕它们的编排机制：它运行循环、强制执行限制，并决定何时停止。
一旦你做出了几个这样的系统，就会发现真正让人瞩目的地方：困难的工作里，关于“模型本身”的部分其实少得多。模型在很大程度上是一个固定选择：你挑一个、给它提示，然后就继续往下走。工程投入更多放在它周围的那些部分。好的工具、好的上下文处理以及好的编排，才是把一次性跑通的演示和你可以持续运行的系统区分开来的关键。那些在提示词措辞上反复琢磨，却忽略这些部分的团队，往往会在周二做出看起来很惊艳的东西，而在周五就坏掉了。
工具和上下文才是真正的表面
如果循环是骨架，那么工具与上下文就是工程真正发生的地方。
工具就是模型的手。它让智能体读取数据库、发送消息、运行查询或移动文件。你的工具质量决定了智能体能做到什么的上限；而工具设计竟然也会成为一种独立的“手艺”。一个好的工具只做一件清晰的事，并提供名称和描述，让模型能非常明确地知道：什么时候该去调用它；同时检查输入，并返回容易被执行操作的结果。描述含糊、意义不明确的工具，甚至比完全没有工具还糟糕，因为模型会自信地、错误地使用它。在为一个强大但陌生的新同事设计接口时，你会投入的那种认真程度，基本就是一个工具应当获得的认真程度，因为情境大体是一样的。
上下文是另一半。模型只知道你放在它面前的内容，所以每一轮你都在回答一个安静的问题：为了做出更好的选择，模型此刻需要看什么？“上下文工程”这个说法正是从这里来的，它也已成为该领域的核心问题之一。原始做法是把更多东西塞进窗口：更多历史、更长的文本、更大量的文档、更密集的指令。这样做并不具备可扩展性。注意力会被稀释，成本不断上升，而模型开始错过真正重要的那一项。更好的做法是把上下文当作一笔预算，用在该用的地方：你检索相关内容，概括旧信息，丢掉已经完成的部分，并保持工作集合小而锋利。把这件事做对，往往就是区分一个能在长任务中保持连贯性的智能体，和一个会慢慢失去方向、逐渐跑偏的智能体之间的关键差别。
为什么智能体很难
下面是每个团队最终都会发现的令人不适的事实：一次单独的模型调用通常还算可靠。把二十次调用串在一起，小小的错误率会相互叠加，最终导致系统失败的概率反而高于成功。
这算起来是无情的。假如一个十步任务里的每一步在95%的时间里都是正确的，那么整个任务成功率也只有大约60%，而这还假设错误是相互独立的——实际上往往并非如此。前面某一次糟糕的观察就可能“毒化”后续的每一个决策。这种叠加效应，是导致那些在演示里让人惊艳的智能体，在生产环境里却挣扎不前的最大单一原因。演示只是“一条顺利的幸福路径”。生产是“成千上万条路径”，而长尾里充满了那些没人想到去考虑的输入。
当你看得足够多之后，失败模式也会发展出自己的“性格”。智能体会卡在循环里，一次又一次地调用同一个工具，并期望得到不同的回答。它会幻觉一个根本不存在的工具或结果。它在什么都没完成时就宣告成功。它会安静而坚定地执行错误的任务，并且完全有自信。没有一项是你能用堆栈跟踪去追查出来的“bug”。这些是你必须提前设计来对抗的行为：要能检测它们何时发生，并优雅地恢复。接受这些问题的存在、不要指望换一个更好的模型就能让一切消失，才是能把智能体真正“交付上线”的团队，区别于那些只会“演示”的团队的地方。
评测（evals）与可观测性
如果智能体以微妙、会叠加、难以预测的方式失败，那么你最该构建的就不只是智能体本身。更重要的是：你要能看见它在做什么，并衡量你的改动是否让它变得更好。
可观测性应当优先。你无法调试看不见的东西，而智能体的推理默认是不可见的。每一次运行都应该留下痕迹：智能体看到了什么、它做了什么决定、它调用了哪些工具、返回了什么，以及它最终停在了哪里。第一次在生产环境中出现让人摸不着头脑的行为时，这些痕迹可能就是5分钟定位与5小时定位之间的差别。把它当作基础设施来对待，而不是之后再补上的“附加项”。
评测（evals）紧随其后，它才是真正推动进步的发动机。评测是一种可重复的测试，用来验证你的系统是否在你关心的用例中完成了它应该完成的事。没有评测，你就在盲飞，因为智能体的陷阱在于：每一次改动在当下看
