1. 为什么“七要素”和“七个决策点”是同一件事的两面
很多人第一次接触 AI Agent，脑子里蹦出来的第一个问题往往是“它和直接调 LLM 有什么区别”。我刚开始做 Agent 项目时也卡在这个点上，后来才想明白：LLM 是一个无状态的函数，Agent 是一个有状态的循环。这个循环里，模型不再只是“回答问题”，而是“决定下一步做什么”。而“七要素”和“七个决策点”其实是从两个视角看同一个工程问题——前者是静态的组成清单，后者是动态的运行时刻。
先说说七要素。业界比较通用的拆法是：模型（Model）、指令（Instructions）、工具（Tools）、记忆（Memory）、编排（Orchestration）、护栏（Guardrails）、可观测性（Observability）。这七个东西不是随便凑的，它们对应了 Agent 从“能跑”到“能上生产”的完整链路。模型是大脑，指令是行为准则，工具是手脚，记忆是经验，编排是调度中枢，护栏是刹车，可观测性是仪表盘。缺了任何一个，Agent 要么跑不起来，要么跑起来之后你根本不敢让它碰真实业务。
但光有七要素还不够，因为要素是静态的，真正决定 Agent 行为质量的是运行时的七个决策点。我把它总结为：要不要调用工具、调用哪个工具、参数怎么填、结果怎么解读、要不要继续循环、什么时候终止、失败了怎么恢复。这七个决策点分布在 Agent 的每一次迭代里，每一个决策点做错了，整个任务就可能跑偏。
为什么说它们是同一件事的两面？因为七要素里的每一个，本质上都是为了支撑某个决策点。工具集的设计决定了“调用哪个工具”的上限，记忆机制决定了“结果怎么解读”的上下文质量，编排逻辑决定了“要不要继续循环”的判断依据，护栏决定了“什么时候终止”的边界。你在设计七要素时做的每一个选择，都会在七个决策点上体现出来。反过来，你在调试时发现某个决策点总是出错，往往要回到七要素层面去找根因。
我见过不少团队，上来就堆工具、堆 prompt，结果 Agent 跑起来像个无头苍蝇。问题不在于工具不够多，而在于他们没有意识到：每增加一个工具，就增加了一个决策点的复杂度。工具从 3 个增加到 10 个，模型在“调用哪个工具”这个决策点上的准确率会明显下降。这不是模型不行，而是决策空间变大了。所以七要素的设计，本质上是在控制七个决策点的难度。
提示：如果你刚开始搭 Agent，建议先把工具控制在 5 个以内，把编排逻辑写死，等跑通了再逐步放开。一上来就追求“通用 Agent”，大概率会在决策点上反复翻车。
2. 模型与指令：决策点的起点在哪里
2.1 模型选型不是“越强越好”，而是“匹配决策复杂度”
选模型这件事，我踩过最大的坑就是“无脑上最强模型”。早期做 Agent 时，我默认用当时能力最强的模型，结果发现两个问题：一是成本高得离谱，二是强模型在简单决策点上反而容易“想太多”。比如一个只需要判断“要不要查天气”的场景，强模型会反复推理、绕圈子，而一个中等模型直接给出判断，又快又准。
后来我总结出一个原则：模型能力要匹配决策点的复杂度，而不是匹配任务的整体难度。一个 Agent 任务里，不同决策点的难度是不一样的。“要不要调用工具”通常比较简单，“参数怎么填”中等，“结果怎么解读”和“失败了怎么恢复”往往最难。如果你的 Agent 大部分决策点都是简单的，用中等模型就够了；只有当“结果解读”和“恢复策略”这两个决策点确实复杂时，才值得上强模型。
具体怎么判断？我的做法是先用一个中等模型跑一遍完整流程，记录每个决策点的错误率。如果某个决策点的错误率超过 15%，再考虑换更强的模型专门处理这个环节。这种“分环节选型”的思路，比整体换模型更省钱，也更精准。
还有一个容易被忽略的点：模型的上下文窗口和决策点数量是强相关的。Agent 每循环一次，上下文里就多一轮工具调用记录。如果窗口不够大，早期的指令和记忆会被挤掉，导致“结果怎么解读”这个决策点失去依据。所以选模型时，不能只看推理能力，还要看窗口大小能不能撑住你预期的最大循环轮数。
2.2 指令设计的核心是“约束决策边界”，不是“描述任务”
很多人写 Agent 指令，习惯写成任务说明书：“你是一个助手，用户会问你问题，你要帮用户解决”。这种写法对 LLM 够用，但对 Agent 远远不够。因为 Agent 的指令要约束的是决策行为，而不是描述任务目标。
我现在的写法是：每一条指令都对应一个决策点的边界。比如：
- “当用户问题涉及实时数据时，必须调用搜索工具，不得凭记忆回答”——这是在约束“要不要调用工具”这个决策点。
- “调用工具前，先确认参数中的时间范围，如果用户未指定，默认取最近 7 天”——这是在约束“参数怎么填”。
- “如果工具返回空结果，最多重试一次，重试时放宽参数范围，仍为空则告知用户”——这是在约束“失败了怎么恢复”。
这种写法的好处是，每个决策点都有明确的规则兜底，模型不需要在每个环节都“自由发挥”。实测下来，这种指令结构能把“调用哪个工具”的准确率提升 20% 以上，因为模型不需要在模糊的指令里猜你的意图。
还有一个技巧：把指令按决策点分组，而不是按功能分组。比如把所有关于“终止条件”的规则放在一起，把所有关于“工具选择”的规则放在一起。这样模型在进入某个决策点时，能快速定位到相关规则，减少跨段推理的负担。
注意：指令不是越长越好。我见过一份 3000 字的指令，里面 80% 的内容是任务背景介绍，真正约束决策的规则只有几百字。结果模型经常忽略关键规则。建议把任务背景压缩到 200 字以内，把省下来的篇幅留给决策规则。
3. 工具与记忆：决策点的信息基础
3.1 工具描述的质量，直接决定“调用哪个工具”的准确率
工具调用是 Agent 最核心的能力，也是最容易出问题的地方。我做过一个统计：在 Agent 的各类错误中，“调用了错误的工具”占比超过 40%。而其中大部分错误，根源不在模型，而在工具描述写得不够好。
工具描述的核心是让模型在“调用哪个工具”这个决策点上，能快速判断“这个工具能不能解决当前问题”。我总结了一个三段式写法：
- 一句话说明工具做什么：用最直白的语言，不要用专业术语。比如“查询指定城市的实时天气”，而不是“获取气象数据接口”。
- 明确适用场景和不适用场景：这是最容易被忽略的部分。比如“适用于查询未来 7 天内的天气，不适用于查询历史天气”。有了这句，模型在“要不要调用工具”时就有了判断依据。
- 参数说明要包含默认值和边界：比如“日期参数格式为 YYYY-MM-DD，默认为今天，最早不能超过 7 天前”。这样模型在“参数怎么填”时不会瞎猜。
我实测过，把工具描述从“一句话”升级到“三段式”，工具选择准确率能从 65% 提升到 85% 左右。这个投入产出比非常高，值得花时间打磨。
还有一个坑：工具数量超过 10 个之后，模型的选择准确率会明显下降。这时候有两个解法：一是做工具分组，让模型先选组再选工具；二是做工具路由，用一个轻量模型先做初筛。我一般推荐前者，因为实现简单，而且分组本身也是对业务逻辑的梳理。
3.2 记忆不是“存聊天记录”，而是“为决策点提供依据”
记忆这个要素，很多人理解得太简单，以为就是把历史对话存下来。但 Agent 的记忆要解决的是一个具体问题：在“结果怎么解读”和“要不要继续循环”这两个决策点上，模型需要哪些历史信息。
我把 Agent 记忆分成三层：
- 短期记忆：当前任务的对话历史和工具调用记录。这层记忆决定了模型能不能理解“上一步做了什么”。
- 长期记忆：跨任务的经验和知识。比如“上次查这个城市的天气，接口返回了空值，后来发现是城市名拼写问题”。这层记忆决定了模型能不能避免重复犯错。
- 工作记忆：当前任务的中间状态。比如“已经查了 3 个城市，还差 2 个”。这层记忆决定了模型能不能判断“任务完成了没有”。
三层记忆的存储和检索策略完全不同。短期记忆直接放在上下文里就行，长期记忆需要做向量化检索，工作记忆最好用结构化字段存，而不是塞在 prompt 里。我见过一个项目，把所有记忆都塞进上下文，结果循环到第 5 轮时上下文爆了，模型开始胡言乱语。
提示：工作记忆用结构化字段存，是提升“要不要继续循环”判断准确率的关键。比如用一个 JSON 记录
{"completed": ["北京", "上海"], "pending": ["广州", "深圳"]}，模型一眼就能看出任务进度，不需要从对话历史里自己推断。
4. 编排与护栏：决策点的调度与边界
4.1 编排的本质是“控制决策点的执行顺序”
编排这个词听起来很玄，其实它解决的问题很具体：七个决策点按什么顺序执行，什么条件下跳过某个决策点，什么条件下回退到上一个决策点。
最简单的编排是线性循环：调用模型 → 判断要不要调工具 → 调工具 → 把结果塞回上下文 → 再调用模型。这个循环能跑通 80% 的简单场景。但一旦任务复杂起来，线性循环就不够了。比如一个需要“先查数据、再分析、再生成报告”的任务，如果全程用一个模型一个循环，模型很容易在“结果怎么解读”时把分析和生成混在一起。
我现在的做法是把编排拆成阶段，每个阶段有独立的决策点集合。比如：
| 阶段 | 核心决策点 | 终止条件 |
|---|---|---|
| 信息收集 | 要不要调工具、调哪个、参数怎么填 | 收集到足够信息或达到最大轮数 |
| 分析推理 | 结果怎么解读、要不要继续循环 | 得出明确结论 |
| 结果生成 | 什么时候终止、失败了怎么恢复 | 生成完整输出 |
这种分阶段编排的好处是，每个阶段的决策点数量可控，模型不需要在一个循环里同时处理所有决策。实测下来，分阶段编排能把复杂任务的完成率提升 30% 以上。
但分阶段也有代价：阶段之间的状态传递需要额外设计。我的经验是，阶段之间只传递结构化的工作记忆，不传递原始对话历史。这样既能保持上下文干净，又能让每个阶段的模型专注于自己的决策点。
4.2 护栏要卡在决策点上，而不是卡在输出上
护栏最常见的做法是在最后检查输出内容，比如过滤敏感词、检查格式。但这种做法有个致命问题：等输出出来再拦，已经晚了。Agent 可能已经调用了不该调用的工具，或者已经循环了 20 轮浪费了大量 token。
我的做法是把护栏前置到决策点上。具体来说：
- 在“要不要调用工具”这个决策点，加一个白名单校验：只允许调用注册过的工具。
- 在“参数怎么填”这个决策点，加一个参数校验：类型不对、范围超限的直接拦截，不让它进入工具调用。
- 在“要不要继续循环”这个决策点，加一个轮数上限和 token 上限：超过阈值强制终止。
- 在“失败了怎么恢复”这个决策点，加一个重试次数上限：超过次数直接降级处理。
这种“决策点护栏”的思路，能把大部分风险拦截在发生之前。我做过对比，前置护栏比后置过滤的拦截效率高 3 倍以上，而且不会浪费 token。
还有一个容易被忽略的护栏：工具返回结果的校验。很多工具会返回空值、错误码或者格式不对的数据，如果直接塞回上下文，模型在“结果怎么解读”时会被误导。我的做法是在工具返回后加一层校验，把异常结果转成结构化的错误信息，再交给模型处理。
5. 可观测性：让七个决策点变得可调试
5.1 没有可观测性，调 Agent 就是盲人摸象
Agent 调试最痛苦的地方在于：你看到的是最终输出，但不知道中间七个决策点分别做了什么选择。输出错了，可能是工具选错了，可能是参数填错了，可能是结果解读错了，也可能是循环该停没停。没有可观测性，你只能靠猜。
我现在做 Agent 项目，第一件事就是搭可观测性。核心是记录每个决策点的输入和输出：
- 决策点：要不要调用工具 → 记录模型判断结果和依据
- 决策点：调用哪个工具 → 记录候选工具列表和最终选择
- 决策点：参数怎么填 → 记录参数值和来源（用户输入还是模型推断）
- 决策点：结果怎么解读 → 记录工具返回原文和模型解读结果
- 决策点：要不要继续循环 → 记录当前轮数和判断依据
- 决策点：什么时候终止 → 记录终止原因
- 决策点：失败了怎么恢复 → 记录失败类型和恢复策略
这些记录不需要多复杂，一个结构化的日志表就够了。但有了这些记录，调试效率能提升一个数量级。我之前调一个“工具选择错误”的问题，靠日志 10 分钟就定位到了是工具描述有歧义；如果没有日志，可能要花半天时间反复试。
5.2 用“决策点错误率”驱动优化，而不是凭感觉
可观测性搭好之后，下一步是用数据驱动优化。我的做法是给每个决策点算一个错误率，然后按错误率排序，优先优化错误率最高的那个。
具体怎么算？以“调用哪个工具”为例：如果模型选择了工具 A，但实际应该选工具 B，就算一次错误。把一段时间内的错误次数除以总决策次数，就是错误率。我一般会设一个阈值，比如 15%，超过这个阈值就说明这个决策点需要优化。
优化的手段因决策点而异：
- “要不要调用工具”错误率高 → 检查指令里有没有明确的调用条件
- “调用哪个工具”错误率高 → 检查工具描述有没有歧义，或者工具数量是不是太多了
- “参数怎么填”错误率高 → 检查参数说明有没有默认值和边界
- “结果怎么解读”错误率高 → 检查工具返回格式是不是太随意，或者记忆里有没有足够的上下文
- “要不要继续循环”错误率高 → 检查工作记忆是不是结构化的，或者轮数上限是不是设得太松
这种数据驱动的优化方式，比凭感觉改 prompt 高效得多。我见过太多团队，Agent 效果不好就反复改 prompt，改了几十版还是不行。问题在于他们没有定位到到底是哪个决策点出了问题。
注意：决策点错误率的统计需要人工标注一部分数据作为基准。建议初期每天标注 50 条左右，积累一周就能看出趋势。标注的时候重点标“模型选择”和“正确选择”，不需要标太细。
6. 七个决策点的实战排查链路
6.1 从“输出不对”倒推到具体决策点
实际项目中，最常见的场景是：Agent 跑完了，但输出不对。这时候怎么快速定位是哪个决策点出了问题？我总结了一个倒推排查链路：
第一步，看终止原因。如果 Agent 是正常终止的，说明“什么时候终止”这个决策点没问题；如果是超轮数终止的，说明“要不要继续循环”可能有问题。
第二步，看最后一轮的工具调用。如果最后一轮调用了工具但结果没被用上，说明“结果怎么解读”有问题；如果最后一轮没调工具直接生成输出，说明“要不要调用工具”可能有问题。
第三步，看工具调用记录。如果调用了错误的工具，问题在“调用哪个工具”；如果工具对了但参数不对，问题在“参数怎么填”。
第四步，看失败恢复记录。如果有重试但重试后还是失败，问题在“失败了怎么恢复”。
这个链路能覆盖 90% 以上的排查场景。我一般会把它做成一个检查清单，每次出问题就按顺序过一遍，基本能在 15 分钟内定位到根因。
6.2 三个高频坑和对应的修复方案
坑一：工具描述太相似，模型反复选错。我遇到过两个工具，一个叫“查询订单”，一个叫“查询订单详情”，描述也很接近。模型在“调用哪个工具”时错误率高达 40%。修复方案是把两个工具合并成一个，用参数区分查询深度。合并后错误率降到 5% 以下。
坑二：工作记忆没结构化，模型判断不了进度。有个任务需要处理 10 个城市的数据，模型处理到第 6 个时开始重复处理第 3 个。原因是工作记忆里只有对话历史，模型需要自己从历史里推断“哪些处理过了”。修复方案是把工作记忆改成结构化字段，记录已完成和待处理列表。修复后重复处理的问题消失了。
坑三：失败恢复没有上限，模型陷入死循环。有个工具经常返回超时，模型每次都重试，重试了 10 次还在重试。修复方案是在“失败了怎么恢复”这个决策点加一个重试上限，超过 3 次就降级返回缓存数据。修复后单次任务的平均耗时下降了 60%。
这三个坑的共同点是：问题不在模型能力，而在七要素的设计。工具描述、记忆结构、护栏规则，这些都是工程问题，不是模型问题。把工程问题解决好，模型的能力才能发挥出来。
7. 从七要素到七个决策点的落地检查清单
7.1 上线前必须过的七道检查
我在 Agent 上线前会过一遍检查清单，每一项对应一个要素和一个决策点：
- 模型检查：上下文窗口能不能撑住预期最大轮数？分环节选型有没有做？
- 指令检查：每条指令是不是都对应一个决策点的边界？有没有模糊表述？
- 工具检查：工具数量是不是控制在 10 个以内？描述是不是三段式？有没有相似工具需要合并？
- 记忆检查：工作记忆是不是结构化的？长期记忆有没有检索策略？短期记忆会不会爆上下文？
- 编排检查：有没有分阶段？阶段之间状态传递是不是只传结构化数据？
- 护栏检查：每个决策点有没有对应的护栏？重试有没有上限？轮数有没有上限？
- 可观测性检查：七个决策点的输入输出是不是都记录了？能不能算错误率？
这七道检查过完，Agent 基本能达到“敢上生产”的水平。我见过很多项目跳过检查直接上线，结果在真实流量下各种翻车，回头补检查的成本比一开始就做高得多。
7.2 一个最小可用的 Agent 骨架
如果你现在就要动手搭一个 Agent，我建议从最小骨架开始。骨架只需要包含：一个模型、一份约束决策点的指令、3 个工具、结构化工作记忆、线性编排、轮数上限护栏、决策点日志。这个骨架能跑通大部分简单任务，而且每个部分都留了扩展空间。
等骨架跑通之后，再按需扩展：工具不够就加工具，但加之前先检查描述质量；记忆不够就加长期记忆，但先确保工作记忆是结构化的；编排不够就分阶段，但先确保阶段之间状态传递是干净的。这种“先跑通再扩展”的思路，比一开始就设计大而全的架构更靠谱。
我在实际项目中的体会是：Agent 的工程质量，80% 取决于七要素的设计，20% 取决于模型能力。很多人把精力花在换模型上，但真正该花时间的是工具描述、记忆结构、护栏规则这些工程细节。把这些做好，中等模型也能跑出很好的效果；做不好，最强模型也救不了。
