第 19 章：Agent
把模型推理、工具、Memory 和受控执行循环组合起来，使系统能够围绕目标进行多步决策。
前言
普通 Chat 一次请求生成一次回答；Agent 面对的是目标，可能需要观察状态、选择工具、读取结果并继续下一步，直到完成或触发停止条件。
一、Agent 是什么
Agent 是围绕目标运行的受控执行系统，常包含：
- LLM：理解与决策；
- State：保存当前任务状态；
- Planning：决定下一步；
- Tools：执行确定性动作；
- Memory：提供必要历史；
- Loop：根据结果继续或停止；
- Guardrails：权限、预算和人工确认。
二、LLM 与 Agent 的区别
text
LLM：输入 → 生成
Agent：目标 → 决策 → 行动 → 观察 → 再决策Agent 使用 LLM，但 Agent 不是模型本身。执行循环、工具管理和状态控制属于应用框架。
三、Planning
Planning 把目标拆成步骤，可能是显式计划，也可能每轮只决定下一动作。
计划不是事实保证。应用应限制最大步骤数、总耗时、Token 预算和工具范围，防止循环失控。
四、Tool Use
Agent 的行动通常通过工具完成：查询订单、搜索知识、读取文件或调用内部 API。
模型只提出工具调用，应用负责权限校验和执行。写操作、外部消息和资金相关操作应增加人工确认。
五、Memory 与 State
Memory 保存可复用的对话或经验；State 保存当前任务的阶段、变量和工具结果。二者不能简单混为一个聊天记录列表。
text
Memory：以前发生了什么
State：当前任务进行到哪里六、Execution Loop
text
读取目标与状态
↓
模型选择下一动作
↓
执行工具
↓
保存结果并更新状态
↓
完成？继续：停止每一轮都必须检查停止条件。
七、停止条件
- 目标已经完成；
- 达到最大迭代次数；
- 超过时间或费用预算；
- 工具连续失败；
- 需要用户补充信息；
- 命中高风险操作，等待人工确认；
- 状态无法继续推进。
没有停止条件的 Agent 不是"更自主"，而是不可控。
八、一个订单助手示例
目标：回答"订单什么时候到，如果延误能否补偿？"
text
1. queryOrder 查询状态
2. queryLogistics 查询节点与预计到达
3. queryCompensationPolicy 查询补偿规则
4. 综合工具结果生成回答工具提供事实，模型负责决定调用顺序和组织语言。订单状态不能由模型猜测。
九、Agent 与固定工作流
| 场景 | 更合适方式 |
|---|---|
| 步骤稳定、合规严格 | 固定工作流 |
| 路径随信息动态变化 | Agent |
| 高风险写操作 | 工作流 + 人工确认 |
| 开放式研究与信息收集 | 受限 Agent |
能够用普通代码清晰实现的流程，不必为了"智能"强行改造成 Agent。
十、可观测性
至少记录任务 ID、轮次、模型调用、工具选择、参数摘要、工具结果状态、Token、耗时和停止原因。敏感输入与工具结果必须脱敏。
十一、安全与成本
- 工具白名单和最小权限；
- 最大轮次、超时和预算；
- 写操作幂等与确认；
- 外部内容视为不可信；
- 防止 Prompt Injection 诱导调用工具；
- 对失败和重复动作设置熔断；
- 支持人工接管和审计回放。
十二、从 API 进入源码
text
Agent Builder
↓ 初始化模型、工具与状态
Agent Loop
↓ plan / act / observe
Tool Calling
↓ 更新 State
Stop Condition阅读时重点关注状态结构、循环入口、工具结果如何回写、停止条件和异常恢复。
十三、常见误区
- Agent 等于能聊天的模型：关键是多步执行循环。
- Agent 越自主越好：自主范围必须受业务风险约束。
- 给足工具就能自动完成：工具描述、权限和失败处理仍然关键。
- Memory 越多越聪明：无关历史会增加成本和干扰。
- Agent 可以替代确定性流程：稳定流程通常应优先用代码实现。
十四、本章总结
Agent 把模型、工具、状态和执行循环组合起来。生产价值来自受控地完成多步目标，而不是让模型无限自主运行。
完整源码
text
源码地址：待补充
对应章节：chapter-19-agent参考资料
下一章：ChatClient 为什么存在
下一章进入框架原理篇，从设计角度重新分析 ChatClient 的职责、Fluent API 和它与 ChatModel 的边界。