1. 从能聊到能干活AI Agent 到底比普通 LLM 调用多了什么很多人第一次接触 AI Agent脑子里浮现的画面是一个会自己思考、自己调工具、自己完成任务的智能体。但真上手写代码的时候往往写出来的东西只是一个带函数调用的聊天循环——用户问一句模型决定调哪个工具执行完把结果塞回去再让模型说一句话。这玩意儿到底算不算 Agent我的判断是算但它只是 Agent 的雏形离工程上可靠还差得远。先把概念掰开。普通 LLM 调用是一次性的输入输出映射你给 prompt它给 completion结束。而 AI Agent 的核心变化在于它把一次映射变成了一个带状态、带工具、带循环、带终止条件的决策过程。这个过程中模型不再只是生成文本而是在每一步做选择现在该继续想、该调工具、该问用户、还是该收尾。我习惯用一个类比普通 LLM 像是一个知识渊博但只能坐在椅子上回答问题的顾问Agent 则是给这个顾问配了手、配了脚、配了记事本、配了工具箱还允许他在房间里走来走去、翻资料、试错、回头重来。顾问的脑子没变但能做的事完全不一样了。那七要素是什么这是业界对 Agent 工程实现拆解得比较清楚的一套框架我结合自己的实践重新梳理一遍并且把每个要素对应到你写代码时到底要处理什么要素通俗解释工程上对应什么目标GoalAgent 要完成什么系统提示词 任务描述 成功判定标准规划Planning怎么拆解任务任务分解策略、ReAct、Plan-and-Execute记忆Memory记住什么、忘掉什么短期上下文窗口 长期向量库/结构化存储工具Tools能调用什么外部能力函数定义、参数 schema、执行沙箱行动Action实际执行工具调用、代码执行、API 请求观察Observation看结果工具返回值解析、错误捕获、结果压缩反思Reflection判断做得对不对自检、重试、纠错、终止判断这七个要素不是并列的而是有依赖关系的。没有记忆规划就是无根之木没有观察反思就是瞎猜没有工具行动就退化成再生成一段文本。很多 Agent 项目跑不起来不是模型不行而是这七个要素里有一两个被偷工减料了。举个我踩过的真实例子。早期我做一个自动整理会议纪要并生成待办的 Agent模型能力没问题但经常出现待办事项重复生成的 bug。排查半天发现问题出在记忆要素上我把每一轮的工具返回都原样塞回上下文导致模型看到同一份纪要出现了三次就以为有三份不同的纪要。修复方式很简单——在观察环节做一次去重和摘要压缩而不是无脑拼接。这就是七要素里观察和记忆没配合好的典型症状。所以理解七要素的意义不在于背概念而在于当 Agent 行为异常时你能快速定位是哪个要素出了问题。这是从调 API 的人变成做 Agent 工程的人的第一道分水岭。2. 七个决策点Agent 每一步到底在决定什么如果说七要素是 Agent 的解剖结构那七个决策点就是它的行为逻辑。我更喜欢从决策点的角度去理解 Agent因为写代码的时候你实际在写的就是在某个时刻让模型做一个选择。2.1 决策点一要不要调用工具这是最基础也最容易被低估的决策。模型看到用户问题后第一反应应该是判断我能不能直接回答。能直接答就答不能才调工具。听起来简单但实际中模型经常过度调用工具——明明知道答案还要去查一遍浪费 token 和时间。我的处理经验是在系统提示词里明确写清楚优先直接回答只有在需要实时数据、需要精确计算、需要访问外部系统时才调用工具。同时给工具描述写得足够具体让模型能判断这个工具解决的是哪类问题。工具描述模糊是过度调用的头号原因。2.2 决策点二调用哪个工具当确定要调工具后模型要在多个工具里选。这里最常见的坑是工具功能重叠。比如你同时定义了search_web和query_knowledge_base模型经常分不清该用哪个。解决办法是让工具职责边界清晰或者在描述里写明当问题是关于内部文档时用 A关于公开信息时用 B。2.3 决策点三参数怎么填这是错误率最高的决策点。模型要按工具定义的 schema 填参数但经常出现类型错误、必填项缺失、枚举值乱填。工程上的应对是双重校验模型填完后代码层再做一次 schema 校验不通过就把错误信息返回给模型让它重填。这比单纯依赖模型一次填对可靠得多。2.4 决策点四结果怎么解读工具返回了模型要理解这个结果意味着什么。这里的关键是错误处理。工具可能返回空、返回报错、返回格式不对。如果模型把报错当成正常结果继续往下走整个任务就崩了。我的做法是在观察环节做统一封装成功返回{status: ok, data: ...}失败返回{status: error, reason: ...}让模型能明确区分。2.5 决策点五要不要继续循环执行完一步后模型要判断任务完成了吗。没完成就继续完成了就收尾。这个决策点最容易出现死循环——模型觉得没完成一直调工具调到超时。防御手段是设置最大迭代次数同时在提示词里明确如果连续两次工具返回相同结果说明陷入循环应该停止并汇报。2.6 决策点六要不要向用户澄清有些任务信息不足模型应该主动问用户而不是瞎猜。但模型往往太自信宁可猜也不问。我通常会在提示词里加一条规则当关键参数缺失且无法从上下文推断时必须向用户提问不要假设。2.7 决策点七怎么组织最终回答任务完成后模型要把整个过程的结果组织成用户能看懂的回答。这里要注意的是不要把中间过程全倒出来。用户不关心你调了几次工具只关心结果。所以最终回答应该是干净的结论中间过程可以放在日志里。把这七个决策点串起来你会发现 Agent 的本质就是一连串的 if-else只不过判断逻辑由模型来执行。理解了这一点你写 Agent 的时候就不会再把它当成黑盒而是能精确控制每一个环节。3. 记忆与上下文Agent 工程里最容易被做烂的一环我见过太多 Agent 项目模型选的是顶配工具写得很全但跑起来就是记不住事。问它上一轮说了什么它一脸茫然让它基于之前的结论继续它从头再来。问题几乎都出在记忆设计上。3.1 短期记忆不是把历史全塞进去最朴素的做法是把所有对话历史拼进 prompt。这在轮次少的时候没问题但一旦超过十几轮上下文就会爆炸而且模型会被无关信息干扰。我的经验是短期记忆要做滑动窗口 摘要。保留最近 N 轮原文更早的轮次压缩成一段摘要。摘要由模型生成只保留结论性信息和未完成事项。具体实现上我会维护一个结构化的对话状态conversation_state { recent_turns: [...], # 最近 5 轮原文 summary: ..., # 更早轮次的摘要 pending_tasks: [...], # 未完成的任务 confirmed_facts: {...} # 已确认的关键信息 }每次调用模型前把这个状态序列化成 prompt 的一部分。这样既控制了长度又保证了关键信息不丢。3.2 长期记忆要解决存什么和怎么取长期记忆通常用向量库实现但很多人只做了存没做好取。存的时候把所有对话都 embed 进去取的时候按相似度 top-k 召回结果召回一堆无关内容。我的做法是分层存储事实类信息用户偏好、固定配置存结构化数据库按 key 精确查经验类信息之前怎么解决类似问题存向量库按语义召回。查询时先查结构化再补向量召回两者结合。还有一个细节写入长期记忆要有筛选。不是每句话都值得记。我通常只在任务完成或用户明确表达偏好时才触发写入避免记忆库被垃圾信息污染。3.3 记忆的遗忘机制这点很少有人提但很重要。Agent 如果什么都记时间长了记忆库会变得又大又乱召回质量下降。我一般会加一个时间衰减 访问频率的权重老记忆如果长期没被召回权重降低高频召回的记忆权重升高。这样记忆库会自然新陈代谢。4. 工具调用与容错让 Agent 真的能下地干活工具是 Agent 从嘴炮变成实干的关键。但工具调用也是最容易出问题的地方。我总结了几类高频故障和对应的处理方式。4.1 工具定义的三个原则第一描述要写给人看也要写给模型看。工具描述不是注释是模型判断该不该用的依据。要写清楚这个工具做什么、什么时候用、输入输出是什么、有什么限制。第二参数 schema 要严格。用 JSON Schema 定义类型、必填、枚举都写清楚。模型填错时schema 校验能第一时间拦住。第三工具粒度要适中。太粗一个工具干十件事模型不会用太细十个工具干一件事模型选不过来。我的经验是一个工具对应一个明确的动作参数不超过 5 个。4.2 容错的三层防线Agent 调用工具失败是常态不是异常。所以要设计三层防线第一层参数校验。模型填的参数先过 schema不通过直接返回错误让模型重填。第二层执行超时与重试。工具执行设置超时超时后有限次重试重试还失败就返回明确错误。第三层语义校验。工具返回结果后检查是否符合预期比如搜索返回空、API 返回错误码不符合就触发模型的反思逻辑。4.3 一个真实的容错案例我之前做一个自动查询订单状态的 Agent工具是调内部 API。上线后发现当订单号不存在时API 返回的是 200 状态码但 body 里是错误信息。模型看到 200 就以为成功了把错误信息当成订单详情返回给用户闹了笑话。修复方式是在工具封装层加一层业务语义校验检查返回 body 里是否有error字段有就转成status: error。这个教训让我明白HTTP 层面的成功不等于业务层面的成功Agent 的工具封装必须做业务语义的归一化。5. 规划与反思Agent 从走一步看一步到有章法没有规划的 Agent 是反应式的——用户说一句它动一下。有规划的 Agent 会先想清楚这件事分几步做再逐步执行。这两者的差距在复杂任务上体现得特别明显。5.1 Plan-and-Execute 与 ReAct 的取舍ReAct 是边想边做每一步都根据当前观察决定下一步。优点是灵活缺点是容易跑偏因为没有全局视角。Plan-and-Execute 是先规划再执行先让模型列出一个步骤清单再逐步执行。优点是方向明确缺点是规划可能不准执行中需要动态调整。我的实践是混合使用先用 Plan-and-Execute 生成一个粗粒度的计划3-5 步执行每一步时用 ReAct 处理细节。这样既有全局方向又有局部灵活。5.2 反思不是让模型再想一遍很多人理解的反思是把结果再喂给模型让它检查。这太浅了。真正的反思应该包含三个动作对照目标检查当前结果是否满足最初的目标识别偏差如果有偏差偏差在哪决定修正策略是重试、换方法、还是向用户求助我通常会在提示词里给模型一个反思模板强制它按这个结构输出。这样反思才有产出而不是我觉得还行这种废话。5.3 终止条件要写死反思的终点是终止。终止条件必须明确不能全靠模型判断。我的做法是双保险模型判断任务完成是一个条件代码层的最大迭代次数、最大 token 消耗、最大执行时间是另外的条件。任何一个触发就终止。这样即使模型上头了系统也不会失控。6. 并发、成本与可观测性Agent 上生产必须过的三道坎Demo 跑通和上生产是两回事。我见过太多 Agent 在本地跑得好好的一上生产就各种问题。核心就三道坎并发、成本、可观测性。6.1 并发Agent 不是无状态的普通 API 是无状态的加机器就能扛并发。但 Agent 有状态——每个会话有自己的记忆、自己的执行上下文。这意味着并发不能简单靠加机器解决还要考虑状态的一致性。我的做法是会话状态外置到 Redis 或数据库Agent 实例本身无状态。每个请求带着 session_id 进来从存储里加载状态执行完再写回。这样 Agent 实例可以水平扩展状态由存储层保证一致性。另外要注意工具调用的并发限制。如果 Agent 调的是外部 API要加限流避免把下游打挂。我一般用令牌桶做限流超限的请求排队或降级。6.2 成本token 是烧出来的Agent 的 token 消耗远高于普通对话因为每一轮都要把历史、工具定义、系统提示全带上。一个复杂任务跑下来token 消耗可能是普通对话的几十倍。控制成本的手段有几个上下文压缩前面说的摘要机制、工具定义精简只带当前可能用到的工具、模型分级简单决策用小模型复杂推理用大模型、缓存相同输入直接返回缓存结果。我实测下来这几招组合能把成本压到原来的三分之一左右。6.3 可观测性出问题要能查Agent 的执行链路长出问题时如果只有最终结果根本没法排查。所以必须做全链路追踪每一步的输入、输出、耗时、token 消耗都记录下来。我通常会给每个 Agent 会话生成一个 trace_id每一步决策都打点。这样出问题时能完整回放整个执行过程快速定位是哪一步、哪个决策点出了问题。这个投入在排查阶段能省下大量时间绝对值得。7. 从七要素到七个决策点一套可复用的 Agent 设计检查清单聊了这么多最后我想把这套东西收敛成一个可复用的检查清单。每次设计新 Agent 时我会按这个清单过一遍能避开大部分坑。检查项对应要素/决策点检查问题目标是否明确目标成功标准写清楚了吗模型知道什么叫完成吗规划策略是否选定规划用 ReAct 还是 Plan-and-Execute复杂任务有分解吗记忆是否分层记忆短期和长期分开了吗写入有筛选吗工具边界是否清晰工具每个工具职责单一吗描述够具体吗参数校验是否到位行动schema 校验做了吗错误能回传吗观察是否归一化观察成功/失败格式统一吗业务语义校验做了吗反思是否有结构反思有对照目标的检查吗有修正策略吗终止条件是否双保险决策点五模型判断 代码兜底都有吗并发状态是否外置工程状态存哪能水平扩展吗成本是否可控工程上下文压缩、模型分级、缓存做了吗可观测性是否完整工程全链路追踪有吗能回放吗这份清单不是教条而是一个提醒自己别漏的工具。我自己的经验是Agent 项目出问题90% 都能在这张表里找到对应的漏项。回到最开始那个问题AI Agent 到底比普通 LLM 调用多了什么我的答案是——多了工程。模型能力是天花板但工程实现决定了你能不能摸到那个天花板。七要素是骨架七个决策点是神经而并发、成本、可观测性是让这套系统真正能跑在生产环境里的血肉。把这三层都想清楚你写出来的才不是一个玩具而是一个能扛事的 Agent。最后分享一个我自己的习惯每次 Agent 上线前我会故意用刁钻的输入去测它——信息不全的、自相矛盾的、需要多步才能完成的。这些测试用例往往能暴露出设计里最薄弱的环节。比起等用户来发现问题自己先把自己打一顿成本低得多。