很多程序员第一次听到大模型智能体这个概念时第一反应通常是大模型不都已经能写代码、做推理了吗为什么还要额外搭一套所谓的智能体架构甚至有人把Agent等同于提示词写得好一点。我见过不少团队花了两周时间调prompt最后发现模型还是在关键环节凭空编造数据。问题不在于模型的智商而在于它被设计成一次性回答而不是闭环完成任务。这个大背景下PEAS模型和ReAct架构就成了绕不开的两个理论锚点——前者是经典AI里定义智能体是什么的分析框架后者是大模型时代让智能体真正动起来的运作方式。这篇文章想把这两块内容串起来讲清楚适合正在做Agent应用开发、或者准备用大模型落地自动化流程的程序员参考。1. 为什么大模型已经很会聊天我们还要专门搭一套智能体框架先说一个最容易被忽略的事实大模型在单次对话里本质上是无状态推理器。你丢给它一段文本它吐出一段文本。它不知道这次对话要达到什么目标、不知道当前的进度走到哪一步、更无法主动去查询实时数据。它能写出一段看起来头头是道的旅游攻略但如果真让它订机票它连一个接口都调不动。这不是模型蠢而是它的工作模式决定的——它只有输入-输出这根单行道。智能体的核心价值恰恰是给这个强大的大脑配上身体和反馈回路。一个完整的智能体至少要能把任务拆分成多步、能调用外部工具获取真实信息、能根据执行结果修正下一步动作最后再决定什么时候收尾。经典AI教材里对智能体的定义非常简单通过传感器感知环境通过执行器作用于环境。放到大模型语境下传感器就是模型看到的用户消息、检索结果、工具返回值执行器就是函数调用、代码执行、API请求。模型负责在这两者之间做决策而这个感知-决策-行动-再感知的闭环就是智能体的灵魂。为什么程序员需要专门关注这件事因为大模型的能力边界已经不再是能不能生成文字而是能不能被可靠地放进自动化流程里。如果你的需求只是写一段摘要、改一版文案那单次对话足够。但任何涉及多步骤、外部系统、状态变更的需求——比如自动处理工单、定时巡检服务器、根据用户行为生成个性化报告——都需要一套明确的Agent框架来管理状态和动作。没有这个框架模型就会在第二三步开始跑偏或者原地打转甚至自信地输出一个根本没执行过的结果。我从2023年开始在项目里尝试这类结构最早踩的坑就是把Agent等同于多轮对话。后来发现多轮对话只是形式真正的关键在于决策循环的闭环设计谁定义目标、谁评估进度、谁决定下一步、什么条件下终止。这些问题的答案在PEAS模型里能找到一半在ReAct架构里能找到另一半。2. PEAS四要素放到大模型时代性能度量、环境、执行器、传感器怎么重新翻译PEAS是《人工智能》经典教材里提出的智能体设计分析框架四个字母分别代表性能度量Performance、环境Environment、执行器Actuators、传感器Sensors。它本来的用途是帮你把一个智能体系统描述清楚它要达成什么目标、活在什么世界里、有哪些手段改变世界、有哪些渠道感知世界。这套框架虽然诞生于大模型还没影的年代但用在今天的LLM Agent设计上反而格外顺手因为它的抽象层级足够高。2.1 性能度量如何定义任务完成性能度量是PEAS里第一个要回答的问题怎么判断这个Agent干得好不好经典AI里这个指标往往很明确比如棋类Agent的胜率、扫地机器人的覆盖面积。但到了LLM Agent性能度量经常被模糊成一句生成一个合理的结果这会给后续开发埋雷。具体做项目时我习惯把性能度量拆成两层。最终结果层关心的是任务是否完成比如客服Agent的一次性解决率、代码Agent的测试用例通过率。过程质量层关心的是执行的每一步是否合理比如工具调用次数是否冗余、是否出现了无效的重复查询、有没有在关键步骤上跳过验证直接给结论。区分这两层非常重要因为如果只度量最终结果模型会被诱导着一步到位编答案如果过程度量设得太细模型又会变得畏手畏脚每走一步都要反复确认反而拖慢任务。一个很典型的例子是我在某模拟项目里做的订单查询Agent。最初的性能度量只写了正确回答用户订单状态结果模型在遇到订单号不在数据库时会直接虚构一个状态告诉用户。后来我把性能度量改成用户问题必须匹配到数据库记录后才能回答查不到时必须明确说明未找到模型的行为立刻发生了变化——它会更倾向于调用查询工具而不是凭经验猜。这说明性能度量本身就是在向模型传达价值观它直接影响Agent的行为边界。2.2 环境Agent面对的不是物理世界而是接口世界PEAS里的环境指的是智能体工作所处的世界。对扫地机器人来说环境是一间真实的屋子有墙、有家具、有灰尘。对LLM Agent来说环境是一个接口世界工具API、数据库、知识库、网页内容、其他内部系统甚至正在和你对话的用户本身。这个区别带来的直接后果是LLM Agent的环境描述必须显式地写成提示词。模型看不到你系统里有哪些服务它只能通过你提供的工具清单和环境说明来理解世界。你在工具描述里写了什么、漏了什么直接决定了它认为自己在面对一个什么样的环境。比如你有一个天气查询工具但如果描述里没有说明只能查询未来三天的约束模型就会在用户问下周天气时继续调用这个工具拿到空结果后懵掉。我在实际设计中还有一个体会环境要尽量做减法。很多人给Agent一口气接上十几个工具觉得能力越多越强结果模型在十几个相似工具里频繁选错。环境这东西不是越丰富越好而是越清晰、越可预期越好。就像人到一个陌生的城市手里有一张重点标注的地图比拿到一本厚厚的地图册更容易不迷路。2.3 执行器与传感器函数调用与观察结果如何落地执行器和传感器是智能体与环境交互的两只手。经典定义里执行器改变环境状态传感器从环境读取信息。在LLM Agent里执行器的实现载体是函数调用和API请求传感器的载体是函数返回值和外部数据源返回的文本内容。这里有一个经常被忽略的设计细节传感器的感知带宽有多宽取决于你给模型返回了什么。一次工具调用的返回值如果是几千行的JSON模型很可能被噪音干扰抓不住关键字段。更好的做法是让工具返回值只包含决策所需的信息。比如查询用户订单工具可以直接返回订单X在运输中预计明天送达而不是把整条数据库记录原样丢给模型。执行器方面核心是可观测性和可回滚性。函数调用一旦发出可能会改变真实世界状态——发了一条消息、提交了一笔订单。所以在设计执行器时要给关键动作加上日志和确认机制。在我的项目里凡是涉及写操作的执行器都会在工具层打一条结构化日志记录谁、什么时间、调用了什么、传了什么参数、结果如何。这样即使后续Agent行为异常也能倒查问题。2.4 别把PEAS当实现蓝图它是一张分析体检表学习PEAS时最容易犯的误解是以为照着四个维度填空就能得到一个可运行的Agent。实际上PEAS是一个描述性、分析性框架它的作用是帮你在设计阶段看清边界、发现矛盾而不是告诉你代码怎么组织。它更像体检表检查你的Agent有没有考虑性能标准、有没有明确环境假设、执行器和传感器是否匹配。我见过一个团队设计客服AgentPEAS里的环境写的是用户会通过网页聊天窗口提问但执行器清单里却没接任何能查询工单系统的工具。结果模型只能靠训练时的记忆瞎答。拿起PEAS这张体检表一对照问题立刻暴露环境里有工单查询需求执行器里却没有对应工具感知和行动是断裂的。所以我的建议是每做一个Agent先花半小时把四个格子填满再开始写代码。不用填得多复杂但环境里提到什么信息源执行器里就要有对应工具性能度量里定义了必须查数据库才能回答传感器里就要保证工具真实返回数据。这个自查动作能避免一大半后期返工。3. ReAct架构的核心循环推理、行动、观察为什么缺一不可如果说PEAS回答了Agent是什么、该描述哪些要素那ReAct解决了Agent的决策循环到底该怎么转。ReAct这个名字是Reasoning与Acting的合成核心思想一句话概括让大模型在思考轨迹和外部动作之间交错进行——先想清楚自己知道什么、缺什么然后采取一个动作去补缺观察动作结果再继续思考。这个循环一直重复直到任务完成。3.1 思维链的只看不做困局在ReAct之前很多团队依赖思维链Chain of Thought来提升大模型的推理能力。思维链的套路很有效它让模型把思考过程一步一步写出来减少了跳步带来的错误。但它有一个致命短板思维链的所有推理都发生在模型内部不接触外部信息。模型只能基于训练时见过的数据去推理遇到需要实时数据、最新状态、私有信息的问题它唯一的选择就是编。举例来说你问模型某商品今天是否还有库存思维链可以让它分析如何判断库存但模型根本查不到当前库存表推理再缜密也是空中楼阁。它可能会说根据常见情况推测库存充足这种回答在Demo里看着还行放到生产环境就是事故。问题出在推理和行动是割裂的——模型只负责想没有人负责做。ReAct的贡献就是把这两个环节焊在一起。它不让模型一次性输出全部思考而是允许模型在推理的中途停下来、调用一个工具、看到真实结果、再接着推理。每一个推理片段都建立在最新观察之上而不是建立在对世界的猜测之上。用打比方的话说思维链像是闭着眼睛在脑海里走迷宫ReAct则是每走一步就睁眼看一下路标。3.2 Thought、Action、Observation三件套如何构成闭环ReAct在工程实现上通常表现为一个三步循环对应模型输出的三种内容类型Thought推理模型用自然语言描述自己对当前状态的判断、下一步的计划、选择某个工具的理由。这段推理文本的作用是让模型的决策过程可见、可审计。Action行动模型输出一个结构化的工具调用请求包含工具名和参数。宿主程序负责解析这个请求执行真正的函数。Observation观察工具执行完返回结果作为新的一轮输入回传给模型。模型把观察结果纳入当前上下文继续下一轮Thought。这个循环的关键在于Thought不是可有可无的装饰而是模型的决策依据。我发现一个有意思的规律当模型在Thought里写清楚了用户需要今天的天气我需要调用按日期查询的工具它的参数生成会更准确如果模型没有Thought直接输出Action参数往往会出现缺漏或格式错误。推理文本本质上在帮模型稳定状态表征。工程上实现这个循环并不复杂核心代码甚至几十行就能跑起来。我在第5节会给一个最小实现。但这里想先强调循环的边界条件什么时候该停判断标准是模型的输出里没有Action、只有最终回复说明它认为自己已经收集到足够信息、可以给出答案了。这个信号在代码里就是一个判断分支响应中有工具调用就继续循环没有就输出最终结果。3.3 为什么循环一次幻觉就少一分一个ReAct循环最直观的效果是让模型的每个关键论断都有观察作为锚点。模型说该商品有库存之前它先看到了库存查询工具返回的库存剩余12件。这个锚点把模型的输出从猜测变成了对事实的转述幻觉空间被大幅压缩。当然这不是说ReAct能根除幻觉。它只能保证模型在调用工具后产生的事实性内容更可靠如果工具本身返回的数据有误或者模型在多个观察之间做归纳时出错该幻觉还是会幻觉。但相比纯文本生成错误至少可以被定位——你能在轨迹里看到它是在哪一步基于什么观察得出错误结论。这种可审计性对生产系统来说价值巨大出了问题可以复盘可以加规则可以修工具。实际使用中还有一个副作用带来意外好处用户对结果的信任度提高了。当智能体生成答案时附带了自己的推理轨迹和工具调用记录用户能看到它不是瞎说的它真去查了数据库。我在某模拟项目中统计过带观察轨迹的回答用户的二次质疑率明显低于直接给结论的回答。这在客服、运维等场景里是非常实用的提升。4. 支撑循环运转的底层零件记忆、工具注册与安全边界理解ReAct循环之后很多人的第一反应是这也不难。但真正落地时你会发现循环只是骨架运转起来还缺几样器官记忆让Agent记得住上下文工具注册表让模型知道有什么可用安全边界保证它不闯祸。这三样东西没有装好循环跑不了几步就会散架。4.1 记忆体系短期上下文与长期外部存储怎么配合ReAct循环有一个天然问题每一轮新观察都要拼接到历史消息里对话越长上下文越臃肿。这就要区分两类记忆。短期记忆是当前任务上下文包括用户的原始诉求、模型产生的Thought、工具调用记录和Observation。短期记忆直接放在上下文窗口里它的问题是有长度上限而且随着轮数增长token消耗越来越大。长期记忆则是Agent跨会话、跨任务需要保留的信息比如用户偏好、历史工单、项目背景、之前Task的结论。长期记忆通常存放在外部存储中——文本摘要、结构化记录、向量检索库——需要时再取回。我见过不少人把短期记忆和长期记忆混在一起一股脑全塞进上下文结果上下文长度爆炸模型注意力被低频历史信息稀释开始犯低级错误。正确的做法是分层管理对话早期且已经被执行完的步骤压缩成摘要只保留最近若干轮完整轨迹。比如一轮十步的任务可以把前七步压缩成已完成天气查询与路线规划结果经确认为可选A方案后三步保留完整Tool Call细节。模型既知道进度又不会被冗长的历史干扰。长期记忆的取回时机同样重要。取回的信息不是越多越好而是要和当前决策高度相关。拿客服场景举个例子Agent查用户历史工单如果返回最近二十条工单摘要模型反而不知道该参考哪条如果先做一次意图分类只取和当前问题类型相关的三五条历史效果就好很多。记忆系统的设计原则是为决策服务不为存档服务——存下来很容易能恰好在需要时取出来才是本事。4.2 工具注册表描述质量决定调用成功率工具注册表是Agent知道自己有哪些牌能打的依据。对LLM而言工具不是代码里的函数列表而是一段结构化的自然语言描述。模型会根据描述决定该不该用、用哪个、传什么参数。所以工具描述的质量几乎直接等于工具调用的准确率。我在实际项目中整理了一份工具描述的检查项照着填能避免大部分选错工具、参数缺失问题检查项差的做法好的做法工具名handle、do_sthquery_order_status动词对象更清晰功能描述查询信息按订单号查询订单当前物流状态仅支持已发货订单参数说明只列出字段名和类型注明必填/选填、取值范围、格式示例边界约束不写说明数据覆盖范围、失效条件、哪些情况应拒绝调用最容易翻车的点有三个。一是相似工具的区别没写清比如查询天气和查询历史天气同时存在描述里如果不说明一个查未来、一个查过去模型就会随机选。二是参数格式示例缺失模型可能把日期写成自然语言明天而你接口要求YYYY-MM-DD于是调用失败。三是错误返回的语义不明确工具返回ERROR四个字母模型根本不知道是参数错了还是数据不存在下一步就是瞎猜。我自己的习惯是每个工具注册表里都要附带至少一个few-shot示例展示正确的调用方式。特别是那些参数复杂、有前提条件的工具示例比任何描述都管用。工具数量建议控制在20个以内超过这个规模模型的选择开销会激增有必要做一次工具分组或前置意图路由。4.3 白名单与确认机制给Agent装上刹车Agent手里拿着能调外部系统的执行器就意味着它拥有了改变世界的能力。如果一个Agent能自动发送邮件、修改配置、提交订单那么它的一次错误调用就可能是事故。安全设计的底线原则是工具列表本身就是Agent的安全边界凡是没注册的工具模型一律碰不到。在此基础上我强烈建议给敏感操作加一道确认闸门。具体做法是把工具划分成普通类和敏感类。普通类查询天气、读日志、检索文档可以完全自动执行敏感类发送消息、写数据库、操作生产环境则要求Agent先输出行动计划由人工或者规则引擎确认后才真正执行。有人觉得这样会拉低Agent的自动化程度我反而认为这正是Agent能上生产的前提。自动化追求的是处理常规任务的效率而不是把决策权完全交给一个不可完全预测的模型。实际操作中确认闸门可以做成异步的Agent在需要敏感操作时先挂起把计划以纯文本发到审批队列人工点一下同意系统继续执行。这个模式的自动化率仍然很高但出大事故的概率急剧下降。5. 一个最小可跑的ReAct循环从模块拆解到完整验证理论讲了不少下面直接上个能跑的东西。我特意把实现压到最简让你看清ReAct循环的内在结构。这个Demo不依赖特定厂商的API只用抽象的llm_chat()函数来表示调用任意一个大模型接口工具也用一个纯Python函数来模拟。5.1 核心循环的代码骨架整个循环的思路是这样的维护一个消息列表把用户问题放进去请求模型生成回复如果回复里带有工具调用请求就在本地执行对应的函数把结果作为一条tool消息追加到消息列表然后再次请求模型直到模型回复里没有工具调用就把当前内容当作最终答案输出。import json # 模拟任意大模型API的封装 # 实际使用时替换为你所使用模型的SDK方法即可 def llm_chat(messages, tools): raise NotImplementedError # 模拟两个工具函数的真实实现 def query_stock(item_id): stock_map {A001: 15, A002: 0} return stock_map.get(item_id, 未知商品) def calc_price(base, discount): return base * discount # 工具分发表从工具名映射到具体函数 TOOL_IMPL { query_stock: lambda args: query_stock(args[item_id]), calc_price: lambda args: calc_price(args[base], args[discount]) } # 工具注册表给模型的JSON描述 TOOLS [ { type: function, function: { name: query_stock, description: 查询商品库存数量返回数字库存为0表示无货, parameters: { type: object, properties: { item_id: {type: string, description: 商品编号如A001} }, required: [item_id] } } }, { type: function, function: { name: calc_price, description: 计算商品折后价格base为原价discount为折扣系数, parameters: { type: object, properties: { base: {type: number}, discount: {type: number} }, required: [base, discount] } } } ]然后是这个Demo的灵魂部分——循环体def run_agent(user_query): messages [{role: user, content: user_query}] for step in range(6): # 限制最大轮次防止死循环 resp llm_chat(messages, toolsTOOLS) assistant_msg resp[message] messages.append({ role: assistant, content: assistant_msg.get(content) or , tool_calls: assistant_msg.get(tool_calls) }) # 如果没有工具调用说明Agent认为可以给出最终答案了 if not assistant_msg.get(tool_calls): print(最终回答:, assistant_msg[content]) return assistant_msg[content] # 逐个执行模型请求的工具调用 for call in assistant_msg[tool_calls]: fn_name call[function][name] fn_args json.loads(call[function][arguments]) print(f[第{step1}步] 调用 {fn_name}, 参数:, fn_args) if fn_name not in TOOL_IMPL: result {error: f未知工具: {fn_name}} else: try: result TOOL_IMPL[fn_name](fn_args) except Exception as e: result {error: str(e)} # 把工具执行结果作为observation追加到上下文 messages.append({ role: tool, tool_call_id: call.get(id, call_demo), content: json.dumps(result) }) print(达到最大轮次任务未在限定步数内完成)这个实现虽然简略但已经完整覆盖了Thought、Action、Observation三要素。模型输出的tool_calls是Action工具执行返回的json.dumps(result)那条消息是Observation而模型每轮回复里先写Thought再决定是否调用的过程由模型自行生成。整个循环是否终止取决于模型自己判断信息够不够。5.2 用它跑一次查天气并安排出行的完整轨迹纸上谈兵不如实际走一遍。假设模型已经接入了上面的循环用户输入是商品A001还有货吗如果有按原价100打八折算一下到手价。模型第一轮生成的可能是这样的内容下面是我在类似项目里见过的高频轨迹Demo结构一致Thought: 用户先问库存再问折后价我需要先查A001库存然后计算价格。 Action: query_stock(item_idA001) Observation: {result: 15}如果你在本地跑会看到循环打印出调用 query_stock, 参数: {item_id: A001}。随后第二轮Thought: 库存为15说明有货。用户要求按100元原价、八折计算discount应为0.8。 Action: calc_price(base100, discount0.8) Observation: {result: 80.0}第三轮模型看到两个观察结果后已经没有未知信息于是不再生成工具调用直接输出最终答案A001有库存共15件按原价100元打八折后到手价80元。注意一个细节模型在没有调用工具之前完全没有办法知道库存是15还是0。它生成查库存动作的唯一依据是Thought里对自己信息缺失的判断。这就是ReAct相比一步生成答案的核心差异。5.3 把这个Demo扩展成生产系统要补什么从Demo到生产中间还差好几层工程活儿。首先模型调用要被可靠封装llm_chat需要支持超时重试、并发控制、流式输出、不同消息角色的正确映射。其次工具执行要做沙箱隔离如果Agent被允许执行代码或访问真实系统工具函数必须放在独立的执行环境里限制文件系统、网络、资源的访问范围。第三是日志与追踪每一轮的Thought、Action、Observation都要结构化落库形成一个task级的完整轨迹记录这样既方便Debug也方便后续回放和评估。还有一点很容易被新手忽略工具返回内容的安全过滤。工具拿到的数据可能包含来自外部的恶意字符串直接拼进上下文再交给模型可能引发提示注入攻击。我的惯例是工具返回值一律转成JSON并做长度截断绝不让工具返回里的指令文本有机会冒充系统提示词。把这些补上之后这个几十行的循环就会膨胀成一个有状态管理、有权限控制、有评测反馈的Agent服务但核心仍然没变——还是那个Thought-Action-Observation的循环。6. 落入真实项目前绕不开的成本、稳定性与评估问题很多团队做Agent Demo时很兴奋跑几个漂亮案例就开始规划上线。但真实项目里的Agent不会只在干净的环境里运行它会遇到上下文膨胀、死循环、模型乱调用这类实际问题。这些问题如果不提前想清楚上线一周就会被逼着回滚。我在这节把踩过的坑集中说一下按成本、稳定性、评估三个方向展开。6.1 token成本会随循环线性膨胀请做好预算ReAct循环每多跑一轮就要把此前全部消息重新送给模型一次token消耗不是线性而是近似平方级增长。一次十轮的任务消耗的token往往是一个五轮任务的三倍以上而不是两倍。配置一个查库存再计算价格的小任务用户可能只说了十几个字最终却烧掉几千token只是因为循环里反复携带了大量工具定义和历史观察。省钱有几个实际手段。第一工具定义不需要每轮都重发。有些API协议允许把tools参数单独设置但在消息历史上很多实现依然会重复发送尽量用支持tools缓存或引用机制的调用方式。第二历史消息压缩。前面讲过把早期已完成的步骤压缩成一行摘要能显著降低每轮开销。第三区分规划模型和执行模型。规划模型用廉价快速的模型负责生成Thought和选择工具执行模型只处理被选中的具体动作参数这种分层架构成本能压到原来的几分之一。成本预算上我建议每个Agent任务上线前先跑三个典型场景统计每类场景的平均轮数和token数再乘上预期的任务量得到一个基准线。后续如果发现token突然翻倍多半是循环逻辑出了偏差比如模型在反复调用同一个查询工具这时候该排查的不是费用而是工具描述或上下文里有没有误导信息。6.2 死循环与过调用最大步数以外的防御手段ReAct循环最经典的故障就是死循环——模型反复调用同一个工具或者连续调用功能相似的几个工具始终得不到能推进任务的信息于是又发起同样的请求周而复始。最简单粗暴的防御是设一个最大循环次数比如6到10轮超出就强制终止并让用户进一步澄清。但最大步数只是最后一道保险丝真要减少死循环还得从源头找原因。死循环的根因通常有三个。第一个是工具返回的信息不足以支撑决策。比如查询接口返回了查询失败但没说明为什么失败模型只能再查一次碰运气。解决办法是让工具错误信息具备足够语义。第二个是工具描述导致错误选择。模型发现自己调用的工具不符合预期退回来想找替代工具找不到就轮番试。第三个是任务本身在当前工具集下无解。Agent没有能力获取某个数据但任务又要求这个数据于是反复尝试。针对无解的情况最好的做法是想办法让模型尽早承认能力边界而不是硬试。我见过一个方案很有效在系统提示词里明确写一句如果尝试两个不同工具后仍无法获取必需信息直接告知用户当前无法完成并说明缺少的信息类型。这句话把承认失败变成一个合法的终止分支让Agent可以体面退出循环而不是无脑空转。过调用是另一个隐性成本黑洞即模型为了一个简单问题连续调用多个工具实际上第一个工具已经给出了足够信息。减少过调用同样要从描述和示例入手在工具注册表的示例里展示最简调用路径同时设一个统一的自检规则只有在消息历史中没有任何信息能回答用户当前问题时才调用新工具。6.3 评测与可观测性没有反馈闭环的Agent是盲飞最后一个容易在项目后期才暴露的问题是怎么证明Agent真的可用大模型输出有随机性同一个任务今天能跑通明天可能换一种做法。如果不建立评测机制Agent就是盲飞状态。我给Agent项目配评测集时至少覆盖三类样本。标准路径样本若干条预期在N步内完成的常规任务用来验证基本能力不退化。边界条件样本包括超出工具能力的问题、歧义提问、需要澄清历史的场景用来验证Agent不会乱来。故障注入样本人为让工具返回错误观察Agent是否能合理应对。评测指标不单看最终回答正确率还要看工具调用精确率——该调用的工具有没有调用、不该调用的有没有多调、参数是否每次都合法。我见过一个Agent最终回答正确率高达90%但工具调用精确率只有60%这意味着它有三分之一的操作是无意义甚至有害的只是恰好没影响最终结果。可观测性方面我强烈建议从第一天就接入完整的轨迹日志。每轮循环至少记录时间戳、轮次序号、Thought原文、Action的工具名与参数、Observation的返回摘要、本轮token消耗。把这些日志结构化存起来后续既能做离线评测也能在用户投诉时快速定位原因。没有反馈闭环的Agent系统出问题时排查效率会低到让人崩溃——你只知道它给了一个错误答案却完全不知道它当时在想什么、做了哪几步、在哪一步开始偏离。做Agent项目这两年我最大的体会是架构上的智能其实没那么玄PEAS和ReAct所提供的本质上是把不可控的大模型封装进一个可控的决策框架里。框架负责纪律模型负责灵活两者配合才能让Agent既聪明又可靠。最后分享一个小技巧新写的Agent别一上来就接太多工具先用一两个工具把一个完整任务跑通、跑稳、跑出日志再逐步扩能力面。先学会走再学跑这条路在Agent工程里同样成立。