LangChain 学习笔记 06：Agent 会做选择，但不该拥有无限权限

让模型回答问题和让模型“去做一件事”，是两种完全不同的风险级别。前者答错了，通常还能被用户发现；后者如果调用了错误工具，可能真的发出邮件、修改数据，甚至产生费用。

第 7 章介绍 Agent、Tool、Toolkit 和 ReAct。它最吸引人的地方是模型可以自己选择下一步，但我读完后最想记住的反而是：选择权必须放在一个受限的动作空间里。

Agent 比 Chain 多了哪一步

固定 Chain 的路线由开发者事先写好。Agent 每轮会根据当前目标和已有结果，决定是调用某个工具，还是直接返回答案。

接收目标
  -> 判断下一步
  -> 选择工具与参数
  -> 执行工具
  -> 观察结果
  -> 继续判断或结束

这个循环让 Agent 能处理路径不固定的任务，例如“查一下上海明天的天气，如果下雨就帮我整理室内活动建议”。模型需要先决定是否查天气，再根据结果继续。

但如果任务路线本来就固定，比如每次都要先查订单再生成回复，那么普通工作流通常更容易测试，也更便宜。

Tool 是系统真正的权限边界

一个工具至少应该明确四件事：它做什么、参数是什么、返回什么、可能产生什么副作用。

“查询订单”可以是只读工具；“取消订单”则有真实副作用。后者不能因为模型生成了合法订单号就直接执行，还需要检查用户身份、订单状态和幂等键，必要时要求二次确认。

我会按风险把工具粗略分层：

风险	示例	建议控制
低	天气查询、知识检索	参数校验、超时、限流
中	创建草稿、生成报表	结果预览、审计日志
高	发信、删数据、付款	最小权限、人工确认、可回滚设计

工具描述也不能只写得“让模型看懂”。真正的安全约束必须落在工具实现里，而不是寄希望于 Prompt 提醒模型谨慎。

ReAct 为什么有效，也为什么会绕圈

ReAct 的基本节奏是推理、行动、观察。模型根据观察结果调整下一步，比一次性猜答案更适合需要外部信息的任务。

问题是，模型可能反复调用同一个工具，参数稍有变化却没有新进展；也可能在错误结果上继续推理。于是 Agent 必须设置最大轮数、总耗时、token 预算和重复调用检测。

工具返回值也要尽量结构化。相比“订单看起来不存在哦”，下面这种结果更容易让 Agent 正确判断：

{"status": "not_found", "order_id": "A1024"}

Agent 的结果也要经过普通代码

即使 Agent 最终给出“应取消订单 A1024”，应用仍要把它视为建议或候选动作。参数要重新校验，权限要重新判断，状态要重新读取。

这是我觉得最容易被忽略的一点：模型参与决策，不代表业务规则可以消失。相反，Agent 越灵活，周围的确定性护栏越重要。

什么时候值得用 Agent

我会先问三个问题：

1. 下一步是否真的无法提前确定？
2. 可用工具是否足够少、边界足够清晰？
3. 出错后是否能停止、追踪和恢复？

如果答案不够明确，我会先用普通函数、路由和工作流实现。Agent 应该解决动态决策问题，而不是用来包装所有模型调用。

这章给我的启发

Agent 的核心能力不是“像人一样思考”，而是在给定目标和工具集合中反复选择动作。它能带来灵活性，也会把不确定性从回答扩展到执行过程。

一个可靠 Agent 的重点，最终不在 Prompt 写得多聪明，而在工具契约、权限隔离、预算限制、停止条件和完整日志是否到位。