本章立足于工程实践，搭建起理解与构建 AI Agent 的基础框架。
可以用公式直观概括：Agent = 大脑 + 眼睛 + 手脚

• LLM 作为大脑，是决策核心；
• 上下文作为眼睛，决定 Agent 能够获取、观测到哪些信息；
• 工具作为手脚，决定 Agent 具备哪些执行能力。
  三大组件缺一不可。

其中，代表感知能力的上下文属于决定性要素。上下文由两部分组成：静态前缀（系统提示词 + 工具定义）、动态轨迹（对话与任务执行历史）。消融实验证明，移除任意组件都会造成 Agent 性能显著衰退。ReAct 循环的本质，就是持续追加任务轨迹，驱动大模型一步步推进目标任务。

Harness 是 Agent 系统构建的核心竞争力。当前大模型能力逐步走向商品化，不同方案之间的核心差距不再是基础模型，而是 Harness。Harness 围绕上下文与工具搭建各类约束、校验、纠错机制，保障 Agent 可靠稳定地完成任务。面向生产环境的 Agent 系统，Harness 绝大多数代码都用于实现这套运行保障体系，而非仅仅实现上下文加载与工具调用。

落地选型顺序建议：先优化提示词 → 再搭建工作流 → 最后引入自主 Agent，这套路径能够最大限度降低系统不可预期行为带来的风险。不同编排模式适配不同业务场景，不存在万能、普适的最优架构。

安全属于顶层架构问题。护栏机制、人工介入、行为对齐（Alignment，令模型行为匹配人类真实意图）必须在项目初期纳入设计，不能等到上线前临时增补安全补丁。安全风险覆盖模型、上下文、工具、多智能体协作、社会影响五大层面。

下一章将深入讲解 Harness 最核心模块：上下文工程。
而 Agent 思想在强化学习领域的学术溯源、传统强化学习与现代 LLM Agent 的详细对比，安排在第七章展开。

下文思考题用于引导读者深挖本章核心概念。

深度思考 · 思考题解答

1. 如果你只能给一个 Agent 系统增加一项能力——更强的模型、更丰富的上下文、还是更多的工具，你会选哪个？在什么条件下你的选择会改变？

优先选择：更丰富的上下文
理由：上下文是Agent的感知边界。缺少充足信息时，更强的模型没有足够依据做出正确判断，再多工具，Agent也不知道何时、如何调用。完整的信息输入是合理决策的前提。

切换选择的边界条件：
1）当信息充足，但模型本身推理能力存在瓶颈，复杂逻辑无法拆解，此时优先升级更强模型；
2）当感知信息充足、模型推理足够，但是缺少执行手段，目标任务需要大量外部操作，此时优先扩充工具集。

2. ReAct 循环中，Agent 的每一次 LLM 调用都会看到完整的历史轨迹。随着轨迹增长，这种设计的成本是二次方增长的。有没有办法在不丢失关键信息的前提下打破这个二次方？

可以通过分层摘要、滚动窗口、关键信息持久化等手段缓解，核心思路是避免每次都传入全部原始轨迹：

1. 滑动窗口机制：保留近期原始交互，久远历史使用结构化摘要替代原始对话；
2. 记忆分层：短期记忆保存原始消息送入上下文；中长期记忆压缩为结构化要点、事件结论；
3. 事件边界摘要：任务阶段性完成后，自动总结本阶段关键动作、结果、约束，丢弃详细过程；
4. 向量检索记忆：不把全部历史塞入上下文，根据当前任务实时检索相关历史片段，实现按需加载；
5. 关键信息标记：区分核心结论与过程日志，仅将影响后续决策的信息持续保留。

注意：不存在零损耗方案，所有压缩手段都会带来少量信息损失，需要业务场景权衡准确率与成本。

3. “模型即 Agent”范式意味着模型在工具调用决策上越来越自主。但本章论证了 Harness 工程的重要性反而在增加。这两个趋势如何共存？Agent 框架未来的核心价值体现在哪些方面？

共存逻辑：
模型自主，解决**“能不能想到调用工具、怎么调用”；
Harness 负责约束、校验、兜底、容错、安全、可观测**。
模型自主性提升，意味着模型犯错、越权、不合理调用工具的可能性同步提升，恰恰更加需要 Harness 作为外部防护层，不能完全信任模型输出。模型负责创造力与自主规划，Harness负责可控性。

未来Agent框架核心价值：

1. 标准化记忆、上下文管理、轨迹压缩能力；
2. 统一的工具鉴权、参数校验、风险管控护栏；
3. 异常检测、循环识别、失败重试、终止策略；
4. 可观测、调试、回放能力；
5. 打通人工接管、人机协同流程；
6. 业务规则与模型解耦，实现模型迭代时业务逻辑稳定。

4. 消融实验中“工具结果反馈”的缺失导致 Agent 陷入无限循环。在生产环境中，除了工具结果缺失，还有哪些情况可能导致 Agent 无限循环？你会设计怎样的检测和终止机制？

容易引发无限循环的场景

1. 工具返回模糊、矛盾、不完整信息，模型反复重试相同调用；
2. 任务目标不可达成（需求冲突、资源不存在），Agent持续尝试无效动作；
3. 模型陷入局部思路，重复执行一模一样的工具调用序列；
4. 缺少状态判别，反复在两个动作之间来回切换；
5. 提示词缺少终止条件定义，模型不知道何时任务完成；
6. 外部系统状态缓慢变化，Agent不断轮询查询。

检测与终止机制

1. 全局最大轮次限制：设置ReAct循环调用次数硬上限；
2. 动作重复检测：识别短周期内完全一致/高度相似的工具调用，触发预警；
3. 状态收敛判断：连续多轮没有产生有效新信息，强制终止；
4. 目标可达性预判：持续无法推进目标时，主动终止并请求人工介入；
5. 轮询冷却策略：针对查询类工具，增加间隔与最大查询次数；
6. 终止分级：轻度循环提醒模型自检；严重循环直接截断任务。

5. 本章用感知、行动、策略三个维度分析了五个 Agent 产品。请选择一个你日常使用的 AI 产品，用这三个维度进行分析，并思考它的架构设计是否合理。如果由你来设计这个 AI 产品，有哪些改进空间？

选取产品：豆包智能体（通用对话Agent）

• 感知（上下文）：感知范围为当前对话窗口历史，具备基础短期记忆；缺少跨会话长期记忆、外部信息主动获取能力；
• 行动（工具）：内置联网搜索、代码执行、文件解析等工具，动作空间开放，但工具调用校验较弱；
• 策略（规划/决策）：依靠LLM原生能力自主判断是否调用工具，无外置复杂规划模块，缺少循环保护。

合理性分析：面向普通C端用户足够轻量化、上手简单；但是面向复杂长任务容易失控、容易循环。
改进空间：

1. 增加分层记忆，区分短期对话与可持久化长期记忆；
2. 增加Harness层，检测无效循环、限制高频工具调用；
3. 增加任务状态感知，能够主动识别任务是否已经完成；
4. 细化工具风险护栏，高风险操作增加确认机制。

6. 如果你要设计一个专门处理航班订票的客服系统，你会选择工作流模式还是自主 Agent 模式？有没有可能在同一个系统中混合使用两种模式？

基础结论：混合架构最优
航班订票存在大量标准化强约束规则（证件格式、退改政策、舱位规则、支付流程），同时存在大量开放式咨询需求。

1. 标准化核心流程（选航班→填写乘客信息→确认订单→支付、退票、改签）：采用工作流模式，流程固定、风险可控、便于合规；
2. 开放式咨询（行李规定、签证关联问题、航班延误政策、复杂场景特殊申请）：使用自主Agent。

混合实现方案：系统设置调度层，首先识别用户意图；标准化业务流转入确定性工作流；无法匹配固定流程的复杂、个性化请求交由自主Agent处理；Agent遇到需要发起订票、改签等关键操作时，切回受严格管控的工作流执行，防止模型违规修改订单、绕过业务规则。

7. 护栏部分提到了工具风险评级。如果一个工具在大多数情况下是低风险的，但在特定参数组合下变为高风险（如 delete_file 删除普通文件 vs 删除系统文件），你会如何设计动态风险评估？

设计动态分级风险引擎，不使用静态标签：

1. 基础风险等级：给工具分配基础风险值；
2. 参数风险规则库：配置参数黑名单、路径正则、资源范围限制；
3. 运行时实时校验：收到模型工具调用参数后，结合目标对象、参数取值、操作类型动态计算实时风险；
4. 风险分级响应：
   • 低风险：直接放行；
   • 中风险：日志审计、增加二次确认；
   • 高风险：直接拦截，拒绝执行；
5. 上下文辅助判断：结合当前任务目标，判断操作意图是否合理；
6. 动态学习与告警：频繁触发临界高风险参数组合，自动更新规则并通知运维。

简言之：风险 = 工具基础风险 + 参数风险 + 任务上下文风险，运行时实时计算，而非预先固定。

8. 本章的 Agent 产品表格中，所有 Agent 的动作空间都是“开放式”的。一个受限的动作空间（比如只能从预定义选项中选择）在什么场景下反而优于开放式？

受限动作空间更合适的场景：

1. 强合规、高风险业务：金融交易、票务下单、数据删除、权限变更，禁止模型构造任意参数；
2. 业务流程高度标准化，所有合法操作可提前枚举；
3. 模型可靠性不足，容易生成错误、非法工具参数；
4. 需要极简调试、可预测系统行为，方便测试与审计；
5. 面向ToB客服、自助办理系统，不允许模型创造未定义操作。

优势：更容易搭建护栏、减少异常调用、结果可预期；缺点是灵活度不足，难以处理未知场景。
简单总结：追求可控、安全、合规优先时，受限动作空间优于开放式；追求探索、复杂开放任务，适合开放动作空间。

9. 人工干预机制要求 Agent 能“优雅地移交控制”。但在实践中，用户可能不在线、响应很慢、或者给出模糊的指令。此时 Agent 应该怎么办？

分层处理策略：

1. 移交前：清晰汇总当前任务状态、可选方案、需要人类做出的决策，降低人类理解成本；
2. 用户不在线/长时间无响应：设置超时策略，区分任务类型：
   • 高风险操作：任务暂停，持续等待，不自动执行；
   • 低风险查询类任务：设定等待时限，超时后终止任务或使用保守默认策略；
3. 用户指令模糊：Agent主动生成澄清问题，结构化列出选项引导人类明确意图，避免自行猜测；
4. 兜底策略：多次澄清仍然无法获得有效指令时，主动终止任务，输出任务中断报告，保留现场便于后续恢复。

核心原则：不确定时绝不擅自执行高风险动作，宁可暂停、终止，不要自主冒险决策。

10. 引言指出“好的设计原则应该穿越模型的迭代周期”。试举一个你认为可能会随模型进步而过时的当前 Agent 设计原则，并说明理由。

待淘汰原则示例：依靠大量人工编写详细系统提示词约束模型行为
理由：
当前LLM指令遵循、复杂规则理解能力有限，工程上极度依赖冗长系统Prompt写入全部业务规则、边界约束。
随着模型持续迭代：

1. 模型可以直接读取外部结构化规则库，不再需要把所有规则塞进上下文；
2. 长提示词带来高昂token成本、上下文拥堵问题；
3. 未来模型可以动态加载外部业务规范，支持规则热更新，修改业务逻辑不需要重写、调试提示词。

长远来看，硬编码海量规则到系统提示词的手段会逐步弱化，取而代之的是外部规则引擎+轻量化提示词。因此“通过超长系统提示词完成行为约束”这条实践原则，会随着模型能力增强慢慢过时。