什么是智能体式人工智能？为何强大？

📄← 模块索引↗ · 📄↑ 总索引↗

完成本节后，你应当能够：

• 解释**什么是智能体式人工智能？为何强大？**对智能体系统的贡献。
• 判断何时该使用它、何时更简单的设计就已足够。
• 将该模式实现为可观察、可测试的组件。
• 识别其主要的成本、安全与可靠性风险。

当质量的提升来自多轮处理而非一次性生成时，使用智能体工作流。

把复杂任务拆分成有边界的步骤，能让模型获得新的上下文、明确的目标，以及使用外部证据的机会。

箭头表示控制流与数据流的走向，不一定对应不同的模型。图中的方框可以由一个确定性函数、被多次调用的同一个模型，或多个不同模型来实现。在整个流程中应保留追踪标识符（trace identifiers）。

1. 写出可衡量的「完成」定义。 在实现之前，先写清楚输入、预期输出、负责人和失败条件。
2. 把任务拆解为输入、转换与输出。 让这一决策在日志或结构化状态中可被观察，以便后续评估。
3. 为每个步骤分配一个明确的职责。 在此边界处应用最小权限原则，并验证相关假设。
4. 定义在各步骤之间传递的状态。 记录结果以及足够复现或诊断所需的元数据。
5. 添加停止规则与最终校验。 在继续之前，将结果与明确的验收标准进行比较。

• 状态（State）： 在结构化的运行记录中保存消息、工具调用、观察结果、产出物、决策理由、尝试次数、token 用量、延迟以及最终状态。
• 契约（Contracts）： 为每个组件定义带类型的输入、带类型的输出、允许的副作用、超时时间和错误类别。
• 控制（Controls）： 使用最小权限凭证、白名单工具、有界循环、输入校验、输出校验，并为有实际影响的动作设置审批关卡。
• 可观测性（Observability）： 在符合隐私规则的前提下，记录 prompt 或其版本、模型与参数、工具参数、工具结果、异常、时间戳和成本。
• 评估（Evaluation）： 测试具有代表性的案例、边界案例、对抗性案例和失败恢复案例，并与最简单可行的基线进行比较。

与其用一条提示直接要一篇文章，不如先生成提纲、逐条核实论点、起草初稿、评审连贯性，再进行修订。

输入：用户目标 + 约束条件
状态：{run_id, step, observations, budget, status}
决策：下一个有边界的动作
校验：权限、参数与策略
执行：模型调用、确定性代码或工具
观察：结构化结果或分类后的错误
停止：验收标准通过、预算用尽，或转交人工

• 该使用场景确实证明了此模式优于更简单的一次性调用。
• 输入、输出与成功标准都已明确。
• 工具调用及其副作用均已校验并获得相应权限。
• 循环设有硬性预算上限和有意义的停止条件。
• 失败情形会触发安全的重试、回退方案，或转交上报。
• 质量、延迟与成本被一并测量。
• 回归测试中至少包含一个失败案例。

1. 什么样的可观察失败，会表明这一模式被误用了？
2. 哪一部分应当是确定性的，而不应交给 LLM 处理？
3. 每一步所需的最小上下文是什么？
4. 人工审批或上报关卡应设在哪个位置？
5. 哪个指标能证明新增的复杂度是值得的？

为一个范围狭窄的任务实现一个最小可行版本。保存三条轨迹：一次成功的运行、一次可恢复的失败，以及一个必须停止或上报的案例。为每条轨迹编写一个回归测试，并将结果与直接生成的基线进行比较。