智能体工程原则

智能体工程并非尽可能为系统加入更多的自主性、记忆、工具使用或模型推理。它是在决定模型介导行为在哪些地方能够创造价值之后，构建围绕该行为的软件，使其具备与其后果相称的上下文、权限、证据与恢复路径。

本手册所称的智能体工程（agent engineering），是设计、构建、评估和运行具有目标导向、工具使用、状态管理、反馈回路与有限自主性的 AI 原生软件系统的工程实践。它不限于构建单个智能体，也不等同于使用智能体辅助软件开发。

本章把“基础”系列的主要认识归纳为九条原则。它们是本手册给出的工程建议，而不是行业标准或成熟度模型。它们都适用于边界明确的模型能力、预定义 AI 工作流和智能体，只是在不同系统中的侧重点有所不同。

论点

有效的智能体系统会给模型介导行为足够的决策空间，使其能够处理语义上的不确定性并根据反馈调整行动，但不会把模型无法可靠承担的责任交给模型。外围系统仍然必须对上下文、状态、权限、证据、恢复和责任归属负责。

这些原则都包含需要权衡的方面，而不是简单口号。使用更多确定性代码不一定更安全或更简单；使用更多智能体机制也不一定代表能力更强或设计更先进。正确边界取决于任务、后果、可逆性和实际观察到的结果。

1. 从任务与结果出发，而非“智能体”标签

在选择架构之前先定义工作：

谁需要什么结果？
是什么让该任务难以用传统规则来明确规定？
哪些输入、判断、动作与例外很重要？
什么算成功、部分成功，或尚未解决的情况？
当系统出错会带来什么后果？

“智能体”并不是产品需求。边界明确的模型操作或预定义工作流，可能以更低成本和更小的出错范围解决任务。相反，开放式任务可能需要模型根据运行情况调整行动，因为事先列举每条路径并不经济。

《什么让一个系统成为 AI 原生？》提出了“必要性测试”：如果移除模型后，系统的核心目的与运行方式基本不变，那么它更可能是带有 AI 增强功能的系统，而不是 AI 原生设计。这是一种客观描述，并不意味着前者较差。

需要权衡的是：只从当前需求出发，可能低估用户在试用中才会发现的新价值。可以把早期原型作为学习工具，但在结果和边界尚未明确之前，不能因为演示效果出色就断言系统能够可靠运行。

2. 只赋予能够带来实际价值的模型决策权

只有当灵活解释或根据反馈调整行动能够改善目标结果时，才把运行时决策交给模型。如果某项流程规则稳定、容易用代码表达，并且必须能够重复执行或强制遵守，就应当把它保留在确定性代码中。

分别从以下维度评估委派：

路径决策权——模型可以决定哪些步骤、分支、工具、重试与停止条件；
行动权限——系统只能提出建议、可以准备操作，还是能够真正执行并影响外部环境；
运行时长——单轮交互、一次有明确边界的运行，还是持续很长时间的工作；以及
人的参与方式——操作、协作、提供建议、审批、处理异常，或仅观察运行情况。

仅在有证据支持时才增加某一维度，而不是因为模型还能再接入一个工具。Anthropic 关于预定义工作流与模型主导智能体的区分，以及仅在能改进结果时才增加复杂度的建议，提供了有用的工程证据（Anthropic, 2024）。它来自 Anthropic 的工程文章，而非通用的架构规则。

需要权衡的是：给模型的决策空间过少，可能会把复杂度转移到脆弱的代码分支中，也可能妨碍系统灵活处理异常。这里的“最少”是指完成工作所需的最低决策空间，而不是尽量减少模型调用次数。

3. 将上下文视为受治理的依赖

每个模型决策都依赖于本次推理所获得的信息。团队需要管理完整上下文，而不只是修改系统提示词（system prompt）的措辞。

对于实质性的决策，需定义：

必需的指令与证据；
权威与允许的来源；
来源与时效性；
冲突与优先级规则；
相关的任务状态与记忆检索条件；
针对用户、检索结果与工具提供内容的信任边界；以及
上下文大小、时延与保留限制。

《上下文工程：让模型获得所需信息》解释了为什么更大的上下文窗口并不保证模型能够有效利用其中的信息，也说明了检索提供的是证据而不是真相。Anthropic 的上下文工程文章同样把上下文视为有限资源，需要持续筛选和整理其中的指令、工具、外部数据与历史记录（Anthropic, 2025）。

需要权衡的是：过度筛选可能漏掉事先没有预料、但对任务非常重要的事实。对于资料范围明确的工作，输入全部资料反而可能更安全。应当评估实际的信息选择方法，而不能把“上下文越少越好”当作普遍规则。

4. 将状态与权限保存在模型的隐含记忆或意图之外

模型可以提出状态变更，也可以描述它认为已经发生的事情。应用程序必须另外保存能够代表当前真实情况的权威记录。

通过显式的系统机制来管理：

任务状态、已完成与待办工作，以及负责人；
事务状态与幂等性；
身份、权限与委托授权；
审批及其范围与有效期；
稳定的用户或组织偏好；以及
可被外部观察到的结果。

对话记录有助于提供证据，但当正确性依赖于当前状态时，它是数据库、账本或任务记录的糟糕替代。已存的记忆也需要范围、有效性、纠正与删除规则。它不应仅因被检索出来就默默地变成权威。

需要权衡的是：明确的状态模型会增加设计与同步成本。一次简短的咨询式交互或许只需要对话记录。只有当任务连续性、协作、对账或实际后果确实要求时，才需要加入持久化的数据结构。

5. 明确表示不确定性和尚未解决的情况

将以下情况区分开来：请求中的歧义、缺失或相互冲突的证据、不同运行之间的差异、环境变化与系统错误。它们需要不同的响应。

定义哪些可以变化，哪些不可以。为系统提供明确路径，例如：

询问澄清；
检索或验证更多证据；
在披露假设的情况下完成；
在证据不足时明确表示无法给出结论；
对安全、隔离的操作进行重试；
回退到范围更小的功能；
请求审批；或
升级到责任人。

仅用 success 与 error 来表示系统状态，会鼓励无依据的确定性，或丢弃有用的部分成果。未决状态应在产品行为、遥测与评估中可见。

需要权衡的是：过多的内部状态会给用户与运维人员带来负担。产品界面可以合并这些状态，或换成更容易理解的表达，但底层的工程区分应当保留，以便系统正确处理和诊断问题。

6. 在模型判断之外强制执行硬性约束

通过指令可以向模型传达规则；但仅靠指令并不能强制执行授权、隐私、事务完整性、预算或不可逆操作边界。

在不可接受违规的地方使用确定性机制：

认证与授权；
最小权限的工具作用域；
数据结构、取值范围、许可清单与规则引擎；
沙箱与资源预算；
事务约束与幂等性；
分阶段执行与审批令牌；以及
输出编码与下游校验。

OWASP 关于提示注入（prompt injection）和权限过大的风险条目说明了：受到操纵的内容一旦与过多权限结合，就可能导致破坏性行为；因此应当在模型之外限制权限，并对重要操作设置真正有效的审批（OWASP LLM01:2025；OWASP LLM06:2025）。这些控制可以限制损害，但不能从根本上杜绝提示注入。

需要权衡的是：每一道硬性边界都会拒绝一部分行为。只有在必须始终成立的约束比开放式灵活性更重要时，才应当强制执行；如果正常工作也可能因此被阻断，还应提供例外处理或升级路径。

7. 用具代表性的工作对整个系统进行评估

用户实际体验到的行为，来自模型与上下文、工具、规则、编排、应用代码和运行环境的共同作用。评估应当面向组装完成的整个系统，并使用接近真实工作的任务。

在相关层级上定义成功：

输出：答案或工作产物；
过程：所用数据、工具、审批与约束；以及
结果：由此产生的状态或效果。

使用典型、边界、对抗以及后果严重的用例。当行为变化会影响产品时，进行多次试验。根据所评估的主张，组合使用确定性检查、人工判断和经过校准的模型评估。不要用公共基准或一次令人信服的运行代替针对本系统取得的证据。

Anthropic 的智能体评估文章明确提出，应把模型与智能体运行框架放在一起评估，并同时观察执行过程与环境中的最终结果（Anthropic, 2026）。更早的生产机器学习研究同样表明，模型质量与数据和软件依赖紧密关联（Sculley et al., 2015）。

需要权衡的是：正式评估可能过早固定仍在探索中的目标。可以先从少量用例和人工审阅开始，随着能力边界与可能后果逐渐明确，再提高评估的严格程度。无论采用哪种方式，都应说明这些证据要支持哪一项具体决策。

8. 为可观测、可中断与可恢复而设计

一个能够连续执行多个步骤的系统，必须提供足够的信息和控制手段来回答以下问题：

是什么目标与配置启动了本次运行？
哪些上下文、工具、状态与审批影响了每个重要决策？
环境发生了什么变化？
工作是在推进、等待、阻塞还是循环？
能否暂停、取消、恢复、重试、回滚，或安全放弃？
失败后还能保留哪些工作产物，哪些外部操作可能已经实际发生？

可观测性并不等同于存储每一个内部 token。系统应在满足隐私、安全与成本要求的前提下，保留诊断问题和追溯责任所需的事件、版本、决策、输入、输出与状态变化。

恢复机制应当成为控制设计的一部分。不要等长时间运行的系统在生产环境中失败后，才去定义停止条件、时间与费用预算、重试边界、检查点、幂等性、回退和升级路径。

需要权衡的是：更多遥测与检查点会增加成本，也会扩大数据暴露风险。只收集能够回答明确运维问题的信息，并对这些证据本身设置访问和保留规则。

9. 明确人和组织的责任归属

模型可以建议或执行一个动作；它无法承担组织层面的后果。

明确哪些人或角色负责：

定义受支持的用途与不可接受的伤害；
审批权限与数据访问；
审阅评估证据与发布；
响应事故与环境变化；
处理升级、申诉与纠正；以及
决定何时应限制或撤回系统。

人类参与必须是有意义的。没有时间、证据、能力或真实拒绝能力的审批对话框，只会制造控制的表象。相反，要求对每一步可逆、低风险的操作都进行审批，会造成疲劳并抹去委派工作的价值。

NIST 的生成式 AI 风险管理框架把风险管理、评估、反馈、人的角色与监督都视为组织在整个生命周期中的责任（NIST AI 600-1, 2024）。具体流程会因使用场景而异，但责任不能交给模型。

需要权衡的是：明确责任也可能演变成官僚化流程。每个角色和审批都应对应具体决策、实际后果与响应路径，而不是增加没有实际作用的签字环节。

原则如何协同

这些原则彼此约束、相互支撑：

任务与结果决定是否值得把决策权交给模型。
交给模型的决策空间决定系统需要什么上下文、权限和恢复控制。
上下文与状态决定系统在每一步能知道什么。
不确定性决定何时应继续、澄清、明确表示无法完成或升级处理。
硬性约束界定了不确定性可以影响的范围。
评估提供证据，证明这些选择能够协同工作。
可观测性与恢复机制让失败能够被诊断和控制。
明确的责任归属确保证据能够转化为负责任的决策。

孤立地优化其中一项，反而可能削弱整个系统。更丰富的上下文如果没有信任边界，会增加数据暴露风险。更多工具如果没有经过评估，会扩大尚未测量的出错范围。更多审批如果没有可供判断的证据，只会制造延迟而不是控制风险。更高的基准分数如果没有对应的系统级结果，可能只是优化了错误的组件。

失效模式

智能体优先的架构

团队在定义任务和结果之前，就选定了框架、记忆系统与工具层。产品需求只能被迫迁就既定技术方案。

将复杂度当作进步

在缺乏对比证据的情况下，更多智能体、更长的计划和额外的反思步骤被直接当作改进。延迟和出错范围增长得比实际价值更快。

只靠提示词执行规则

后果严重的规则只写在指令中。模型既负责解释边界，又负责执行边界；一旦它误解规则或受到操纵，边界也就失去了作用。

隐藏的状态与隐藏的权限

对话记录暗示一个动作已发生或权限存在，而外部系统的真实情况不同。恢复与审计沦为猜测。

架构之后才做评估

成功标准直到系统建成后才出现，于是评估衡量的是实现恰好暴露出的东西，而非用户结果。

记录很多，却仍然看不清运行状态

每次交互都被记录，但无人能识别当前任务状态、已提交的效果、失败原因或责任归属。

人的控制流于形式

人在缺乏足够信息的情况下点击“批准”，或者不断接管一个权限范围和自动化程度本就设计不当的系统。

本手册的建议

在架构评审前使用这份简明记录：

目标用户与预期结果：
模型介导行为为何必不可少：
确定性工作流与交给模型的决策：
委托配置：
必需上下文与权威状态：
允许使用的工具与行动权限：
允许的变化和尚未解决的状态：
硬性约束及其执行位置：
评估任务、试验与结果证据：
观察、停止、恢复与回滚：
人的角色、升级路径与责任归属：
新增复杂度能够改善结果的证据：

若某个答案未知，将其记录为未决设计问题。不要让模型、框架或默认工具权限在不经意间替你作答。

清单

参考文献与使用方式

Anthropic, “Building effective agents” (2024) — Anthropic 工程文章，支持工作流—智能体的控制区分、简单可组合的模式、环境反馈，以及仅在结果证明时才增加复杂度。
OpenAI, “A practical guide to building agents” — OpenAI 面向产品与工程的智能体构建文章，支持模型管理的执行、工具、防护栏、退出条件与人工干预。该文与产品关系紧密，未建立通用的智能体定义。
Anthropic, “Effective context engineering for AI agents” (2025) — 厂商工程经验，支持把上下文视为有限资源，并持续筛选和整理其中的指令、工具、数据与历史。
Anthropic, “Demystifying evals for AI agents” (2026) — 厂商工程经验，支持在任务、试验、执行过程与结果层面共同评估模型和智能体运行框架。
Sculley et al., “Hidden Technical Debt in Machine Learning Systems” (2015) — 生产级 ML 研究，支持从系统层面思考依赖、反馈回路与变化。该文早于生成式模型与智能体。
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1 (2024) — 自愿性的跨行业风险管理资料，支持全生命周期的风险管理、评估、反馈、文档、人类角色与组织监督。
OWASP, “LLM01:2025 Prompt Injection” 和 “LLM06:2025 Excessive Agency” — OWASP 社区风险条目，支持隔离不可信内容、采用最小权限、在模型之外强制执行约束，并对后果严重的操作设置有效控制。它并未宣称这些措施能够提供万无一失的防护。