搞 AI Agent 的朋友应该都有过这种经历Demo 里跑得飞起规划、调工具、给结果一气呵成老板看了直点头。结果一上生产并发一上来上下文一长模型开始“精神分裂”工具调用格式偶尔抽风Agent 陷入死循环疯狂烧 token线上事故一条接一条。问题出在哪很多人第一反应是模型不够聪明换个更强的模型结果该崩还是崩。实际上单点模型能力从来就不是 Agent 稳定性的核心真正决定一个 Agent 能不能从玩具变成生产力工具的是套在它外面的那层工程设施——也就是现在圈里常说的 Harness 工程。这层“马具”干的事很实在用工程手段把大模型的随机性圈在可控的围栏里让它的每一步规划、每一次工具调用、每一轮反思都有迹可循、有错可纠、有账可算。这篇就围绕我自己落地 Agent 服务过程中的经验聊聊 Harness 工程里的核心机制、实操要点以及那些我踩过坑之后才想明白的细节。1. 为什么 Agent 总在 Demo 里封神一上线就崩先说个挺反直觉的事Agent 的稳定性问题往往不是模型不够强而是我们把模型当成了“系统”而它实际上只是个“组件”。大模型本质是一个概率函数同样的输入它可能给出不同的输出这不叫 bug这叫天性。而 Agent 是一个系统系统的第一要求是确定性是可控性是“这次和上次的运行行为保持一致”。用概率组件去搭建确定性系统中间必须有缓冲层这个缓冲层就是 Harness 工程要干的事。1.1 从“能跑”到“能扛”的鸿沟我见过太多团队的第一版 Agent 是这样的一个 prompt 加一个 model 调用中间塞了一堆 tool calling 逻辑跑通了一个端到端场景就认为 Agent 做完了。这种架构有几个明显的隐患没有状态管理Agent 的分支逻辑一旦变多代码里全是if model_response contains ...这种脆弱判断。上下文无限膨胀几轮对话之后 prompt 越来越长模型开始忽略早期指令Agent “失忆”。工具调用结果不校验模型输出了错误的参数代码照样传给 API出错之后直接把错误堆栈丢回给模型让它自己看着办。没有预算控制一个死循环的 Agent 可能把一天的 token 额度在半小时内烧光。这些问题在 Demo 阶段全都不存在因为 Demo 的路径是预设好的输入输出都是挑过的模型的随机性被“样例”掩盖了。但生产环境是开放的、动态的、充满了边界情况。用户不会按你预设的 prompt 来说话也不会配合你的工具 schema 来输入数据。换句话说Demo 证明的是模型的“上限”而 Harness 工程要兜住的是“下限”。1.2 Harness 工程到底在“管”什么“Harness”这个词本身很有意思原意是马的挽具。你给马套上缰绳和鞍具不是为了让它跑得更慢而是为了让它能按你的路径去跑在需要转向的时候转向需要停止的时候停下来。Agent 的 Harness 做的是同一件事套住模型的输出、管理运行时的资源、定义 Agent 的行为边界。Harness 工程的核心构成我用下来总结成四块记忆系统来对抗上下文失忆工具调用协议来约束模型的输出格式护栏机制来圈定行为的边界可观测性层来记录 Agent 的每一个决策和动作。接下来我逐个展开讲一讲每个模块在实操里要注意的细节。2. Agent 稳定性的四个核心机制这四个机制不绑定任何具体框架是通用的工程抽象。无论你是用 LangChain、LangGraph、AutoGen还是自己从零写编排层最后都得实现这些能力差别只在实现方式和坑的深浅上。2.1 记忆系统让 Agent 不“失忆”Agent 跑多轮之后效果变差十有八九是记忆系统没设计好。大模型的上下文窗口有上限而 Agent 运行过程产生的中间信息远远超过窗口长度。计划、工具返回值、用户反馈、历史对话全塞进去很快就会溢出。这里要做的是分层记忆架构。我自己用的方案是三层短期工作记忆当前任务相关的信息比如用户最近几轮输入、当前正在执行的子任务状态。这部分直接放进上下文保证模型“知道现在在干什么”。长期事实记忆用户偏好、项目背景、历史结论。这部分不直接进上下文而是通过向量检索也就是 RAG在需要时召回相关片段。压缩记忆把过去一段完整对话交给一个摘要模型产出一个结构化的“当前任务状态摘要”替换掉原始冗长的历史对话。很多 Agent 框架自带 ConversationBufferMemory 之类的组件但那只是最基础的“聊天记录”不是真正的记忆系统。真正的记忆要解决的是“什么该留、什么该丢、什么该压缩”的问题。我自己习惯在 LangGraph 里单独给记忆加一个节点不管用 Redis 还是向量库核心是给记忆加时间戳和状态标记。这样 Agent 在加载记忆时才能区分“这是上次跑了一半的任务”和“这是一个全新的请求”。2.2 工具调用协议把自然语言变成可靠动作工具调用是目前 Agent 落地最主流的形态。模型生成一个结构化的调用指令Agent 执行它把结果返回给模型继续推理。这听起来简单实际的问题全在细节里。第一个问题是参数幻觉。模型可能生成了工具名和参数但参数内容根本不合法。比如让 Agent 调用一个search_books(title: String, limit: Int)的工具模型可能输出limit: three。这种问题在强模型上出现概率低但生产环境哪怕 1% 的出错率都受不了。我的做法是在 Harness 层加一道“工具调用验证器”在把调用指令真正发给后端服务之前先用 JSON Schema 校验参数类型和必填项不合法就丢回给模型重新生成最多重试两次。这个重试逻辑必须是显式的而不是把错误信息直接拼回 prompt 让模型“自觉”修正——显式重试 修正指引发回成功率会高很多。第二个问题是工具执行结果的体积和形态。很多工具返回的是结构化 JSON但这个 JSON 可能很大。比如数据库查询返回了 1000 行数据直接全塞进上下文token 消耗是其次关键是模型根本抓不住重点。我的做法是先让工具执行然后加一个“结果后处理”节点不管用户调的 API 也好、数据库也好最终返回给模型的工具结果必须是一个裁剪过的、与任务相关的摘要版本。比如 API 返回的完整 JSON我可以在后处理时只保留 top 10 条、只保留关键字段并把字段名改成更语义化的“书名”“价格”“库存”这比原生字段名对模型的“友好度”高得多能显著降低后续推理的出错率。2.3 护栏机制安全与合规的边界护栏听起来像是一个“限制模型”的组件但实操里我更愿意把它理解成“Agent 的边界守卫”。它的职责是持续监控 Agent 的输入和输出判断当前的动作是否越界。边界包括几类行为边界禁止 Agent 在未确认的情况下执行不可逆操作比如删除数据库记录、发送订单、转账。内容边界输出内容不能包含违规信息、不能泄露内部 prompt 或工具 schema。语法边界输出必须符合约定的格式比如必须是合法 JSON、必须包含指定字段。在具体实现上我一般分两层一层是前置校验在 Agent 即将执行工具动作之前跑一个规则引擎判定这个动作的“风险等级”和“是否需要人工确认”另一层是输出校验在 Agent 最终回答用户之前加一个“答案审计”节点把模型生成的回复先过一次内容过滤器和格式校验有问题就阻止输出并触发重新生成。这里要特别说明一点护栏机制不能完全依赖模型“自我约束”。模型天然没有“规则”概念prompt 里写的“绝对不要删除数据”在足够强的诱导下会被绕过。护栏必须放在 Harness 层用代码来裁决而不是用 prompt 来劝告。2.4 可观测性Agent 心智的“行车记录仪”可观测性在 Agent 里比在普通后端服务中更重要因为普通一道 API 出错了你拿 request 和 response 就能定位问题但 Agent 出错了你拿到的是一长串“思考过程、工具调用、中间结果、分支选择”没有可观测性你根本不知道它是在哪一步“想歪的”。我的做法分两个维度运行时日志在每个节点进出的时候记日志包括节点名、输入摘要、输出摘要、耗时、token 消耗。这里有个关键的细节是不要去记录完整的 prompttoken 消耗和隐私成本都不划算。记“摘要”就好比如“用户消息前 200 字 消息长度 消息语言”为的是能定位问题不是复现完整对话。轨迹追踪整条 Agent 运行链路要有一个唯一的 trace_id从用户请求进来到每一步工具调用再到中间模型的每次推理全部串起来。我习惯用 LangSmith 或者自建 trace 表来存按 trace_id 聚合可以回放这个 Agent 在遇到问题之前究竟经历了哪些步骤、读了哪些记忆、调了哪些工具、模型做了哪些决策。这个能力在生产环境几乎是刚需没这个你排查线上问题只能靠猜。3. 循环控制与递归Agent 自我纠错的关键Agent 跑偏对于一个“能干活”的系统来说是个必须认真对待的现实问题。模型不可能每次都生成正确答案Harness 工程能做的是给 Agent 一个“自我纠错”的闭环让它察觉到自己的错误然后修正路径而不是在错误的道路上一路狂奔。3.1 规划-执行-反思循环为什么一定要限制轮数现在主流的 Agent 结构大多是“规划Plan→ 执行Act→ 观察Observe→ 反思Reflect→ 再规划”的循环。这个机制本身没问题它赋予了 Agent 应对复杂任务的灵活性。但没有约束的循环是灾难一个任务可以无限循环下去每一次循环都可能调用工具、消耗 token而结果却是原地打转。我给出的硬性建议是每个任务必须设置最大迭代次数max_iterations和最大 token 预算max_token_budget两个条件任一触发Agent 就立即终止循环并把“当前已完成的子任务清单”和“未完成的障碍描述”返回给用户而不是假装任务成功。这个“假装成功”的问题也需要重视。LLM 在多次尝试之后仍然无法完成任务时倾向于生成一个看起来合理的“最终答案”来结束对话哪怕这个答案并没有真正解决问题。所以 Harness 层必须检测如果 Agent 循环了多轮但最终没有调用任何“最终结果确认”工具那就要标记这个回答为“低置信度”并在返回给用户时明确提示“我经过多次尝试未能完整完成任务以下是我的部分产出和失败原因”。3.2 结构化输出让 Agent 的“思考”被机器解析很多时候 Agent 不稳定不是模型不好用而是我们把模型的输出当成了“自由文本”来解析这就导致了一堆潜在的不稳定因素。比如让模型直接回答“是或否”它可能回答“Yes”“是”“对”“可以”“当然”。这些在人类看来都是同意但代码解析时就完全取决于你写的判断逻辑是否覆盖了所有表达方式。Harness 工程里有一个明确的准则凡是需要被代码消费的模型输出一律用结构化协议来约束。具体到我实操中就是把 Agent 的每一步推理结果都设计成一个 JSON 对象包含固定的 schema。比如在执行工具调用时模型的输出必须是{ thought: 用户需要查询库存我先检查本地缓存, action: search_inventory, action_input: {item_id: SKU-2039, warehouse: SH}, confidence: 0.9 }在代码层强制解析这个 JSON解析失败就重试一次重试还是失败就让模型输出纯文本兜底走一条“降级对话”路径。LangGraph 的create_react_agent或ToolNode都内置了类似机制但我建议即使你在用框架也要自己封装一层结构化输出的校验因为默认实现往往只做“格式校验”不做“语义校验”。还要注意的一个坑是结构化输出和流式输出的冲突。很多 Agent 要面向用户流式输出 token但结构化输出要求模型完整生成一个 JSON 后再解析这两者天然矛盾。我的方案是把对话流和动作流拆开面向用户的“说人话”部分走流式 token面向系统执行的“动作指令”部分走结构化 JSON两个通道互不干扰。这个设计在后面讲代码实战时我会具体演示。4. 并发、Token 与成本稳定背后的资源账本Agent 的稳定性不只是逻辑层面的也是资源层面的。一个逻辑没毛病但动不动就把 GPU 或 API 配额打满的 Agent本质上还是不稳定。4.1 Agent 扛并发和普通 Web 扛并发有什么不同很多人一上来就问“AI Agent 怎么扛并发”实际上这个问题本身就需要拆开。普通 Web 服务的并发模型是“一个请求对应一个处理单元”请求之间相对独立。而 Agent 服务的特点是单个任务会拆成多个子步骤每步都可能调用模型单任务耗时几十秒甚至几分钟。这时候并发压力集中在两个地方任务级并发同时有多少个 Agent 实例在跑任务。模型调用级并发所有 Agent 任务在某一时刻同时调用模型 API造成 upstream 限流例如 429。我踩过的一个坑是任务队列做了并发限制比如最大 10 个任务并发但没做模型调用层的并发控制。结果 10 个 Agent 在规划阶段同时向模型 API 发起 10 个请求恰好赶上官方限流阈值全部 42910 个任务一起失败。后来我在 Harness 层加了一个“模型调用限流器”本质上是一个简单的漏桶或信号量把整个服务的模型 API QPS 控制在一个安全值以下才能避免这种“任务没满但模型调用挤爆”的假并发问题。4.2 Token 成本控制从 token 计价到预算熔断Token 是 Agent 的燃料也是成本的源头。之前提到过要设置 max_token_budget实操里我建议把它细化到每个任务、每个子步骤两个级别。单任务预算比如一个“市场调研”任务执行前预估最多消耗 20K token超过这个值直接终止。怎么预估我一般是先跑几轮真实任务统计平均消耗然后乘一个 2 ~ 3 倍的安全系数作为上限。这个系数要给出余量但又不能给得太宽松否则预算控制形同虚设。单次模型调用预算防止某些模型因为上下文过长单次调用就消耗了巨量 token。比如设定单次模型调用不得超过 8K token如果上下文超过了就触发记忆压缩流程把早期内容先摘要降级再继续。成本控制还有一个容易忽略的点不要对工具返回的原始结果直接再喂给下一轮模型。工具返回的结构化数据该摘要的摘要、该截断的截断这不仅能减少模型“信息过载”的幻觉问题对整个服务的 token 消耗也有立竿见影的效果。别小看这一层后处理有时候省个 40% 的 token 是轻轻松松的。4.3 一剂必要的“降级预案”不要假设模型和外部依赖永远可用。我在生产里必备一整套降级预案按优先级排开模型 API 超时 → 重试一次换同模型不同 region模型 API 限流 → 退避等待队列排队模型连续失败 → 切换小模型 简化 prompt 兜底全部模型不可用 → 返回“当前服务繁忙”的优雅信息不阻塞用户。这个降级链路需要提前压测提前演练。一次真实线上事故里的经验是模型 API 持续报错但因为熔断器已经生效服务自动切换到了降级路径用户只是感觉到了“响应稍慢”而不是“白屏报错”。这个“无感降级”能力的价值不亚于 Agent 本身的逻辑正确性。5. 从零到一一个最小可运行的 Agent 服务前几节讲的都是机制和原则这一节我来一个能直接跑起来的最小闭环用 FastAPI LangGraph 实现覆盖前面说的“会话状态、工具调用、循环控制、结构化输出、流式对话”这几个核心点。5.1 整体架构和选型说明我选型的标准很简单生态成熟、上手快、不锁定供应商。FastAPI 作为服务层LangGraph 作为编排层Redis 做记忆存储可选的向量库比如 Chroma 或 pgvector做 RAG 召回。模型层可以兼容不同厂商的 OpenAI 协议接口生产环境根据成本和质量要求做切换。之所以用 LangGraph是因为它的核心抽象是“图”节点Node是执行单元边Edge是跳转条件状态State是贯穿整个图的上下文。这非常适合表达 Agent 的“规划→执行→反思”循环而且它对循环控制、条件中断有内置支持比我自己写状态机省很多事。5.2 核心代码实战先定义一个简单的状态类用来在 Agent 的各个节点之间传递信息。这里要特别注意State 里不该保存大体积的工具结果而是保存“摘要”和“引用 ID”。需要完整结果的时候再通过 ID 从存储里取。from typing import TypedDict, Optional, List class AgentState(TypedDict): task: str # 用户请求的核心任务 messages: List[dict] # 对话历史轻量摘要 intermediate_result: Optional[str] # 工具执行摘要 tool_calls: List[dict] # 工具调用记录 iteration: int # 当前循环轮数 max_iterations: int 6 # 最大循环轮数 completed: bool # 是否已完成任务工具节点是这个架构里最值得写清楚的地方。每个工具必须做成“可观测、可校验、可裁剪”的。下面的示例是一个查询商品的工具参数类型校验放在函数入口做执行结果在返回前完成裁剪from pydantic import BaseModel, Field class SearchProductInput(BaseModel): keyword: str Field(..., description搜索关键词) limit: int Field(5, ge1, le20, description返回结果条数) def search_product(keyword: str, limit: int 5) - dict: # 实际场景中这里会调用真实商品服务或数据库 raw_results fake_db_query(keyword, limit) # 结果裁剪只保留模型后续推理需要的核心字段 slim_results [ { name: item[name], price: item[price], stock: item[stock], } for item in raw_results[:limit] ] return { summary: f找到 {len(slim_results)} 个商品, items: slim_results, }然后是核心的反射节点。这个节点是整个循环里最“工程味”的一步它的输入是当前任务状态和最近一轮工具执行结果输出是一个结构化的判断告诉图接下来是“继续干活”还是“收工返回”from langgraph.graph import StateGraph, END def reflect_node(state: AgentState) - AgentState: # 这里实现了循环控制轮数上限 if state[iteration] state[max_iterations]: state[completed] False return state # 结构化反思让模型产出一个可解析的判断 reflection_prompt build_reflection_prompt(state) response call_model(reflection_prompt, json_modeTrue) parsed extract_agent_decision(response) # 强制 JSON 解析 if parsed.get(need_more_info): # 还有信息缺口继续规划 state[messages].append({role: assistant, content: parsed[next_plan]}) state[iteration] 1 else: # 信息够了生成最终答案 state[completed] True state[final_answer] parsed[final_answer] return state最后把整个图组装起来入口节点 → 规划节点 → 执行节点工具调用→ 反射节点 → 根据反射结果决定返回还是再进一轮循环。组合的代码很简单graph StateGraph(AgentState) graph.add_node(plan, plan_node) graph.add_node(execute_tool, tool_execute_node) graph.add_node(reflect, reflect_node) graph.set_entry_point(plan) graph.add_edge(plan, execute_tool) graph.add_edge(execute_tool, reflect) graph.add_conditional_edges( reflect, lambda state: plan if not state[completed] else end, {plan: plan, end: END}, ) app graph.compile()FastAPI 层只需要暴露两个接口一个创建任务启动 Agent 执行一个查询任务状态。复杂的 Agent 编排交给 LangGraph 在后台跑避免用户请求长时间占用 HTTP 连接。这个思路我在多个项目里验证过是一个稳定且好维护的形态。5.3 从代码到上线必须补的四层配置代码能跑通只是第一步上线前的配置我一般按下面四层检查第一层服务配置。设置进程级并发数、每个任务的超时时间默认 60 秒超过直接 kill、模型 API 的超时和重试参数。这些参数都要做成环境变量方便在不同环境开发 / 测试 / 生产之间切换。第二层存储配置。Redis 连接池、向量库集合、 trace 记录库。记忆数据要有过期时间不然用户的历史记录和中间状态会无限堆积后面做数据清理的时候想哭。第三层模型配置。不同节点用不同的模型。规划节点用强模型摘要和反思节点可以用弱模型降成本工具的总结输出可以交给小模型。把模型当成不同价位的“工种”来用能省就省该花就花。第四层监控配置。把前面提到的 trace_id、节点耗时、token 消耗全部接入监控面板。对“平均迭代轮数”“平均单任务 look 次数”“工具调用失败率”这些 Agent 特有的指标重点盯。6. 生产环境常见故障排查实录这节直接上一线经验。以下问题都是我在实际跑 Agent 服务时反复遇到的前几名选手每个都给出了排查思路和处理方案做成了速查表方便对号入座。现象根因排查思路解决方案Agent 答非所问上下文被早期指令淹没查 trace 里模型实际收到的 prompt看指令顺序是否有问题把系统指令放到 prompt 末尾或压缩历史记录工具调用格式不稳定强模型偶发幻觉抓取原始模型输出看是参数幻觉还是 schema 问题加显式重试 JSON Schema 校验最多重试 2 次同一任务反复执行同一工具Agent 陷入循环检查 reflect 节点是否真正在“反思”还是只是机械地继续调工具在 reflect 节点加入“本次循环相比上次的新增信息”检测无新增立即终止Token 消耗远超预期没有按语义裁剪工具结果看 trace 里面工具返回的 token 占比给工具结果加裁剪摘要层只返回与任务相关字段模型 API 429任务级并发未控制到模型调用级看监控里模型 API 的 QPS找出请求集中爆发的瞬间加信号量 / 漏桶限流模型调用层单独排队用户长时间等待无响应Agent 执行了太多工具步骤看平均任务耗时和工具调用次数限制子任务数量增加“进度上报”机制用户端显示阶段性状态Agent 直接“编造”结果模型没有真实调用工具就产出了答案检查工具执行节点是否被跳过检查是否走了降级路径对关键业务动作强制绑定工具调用不调用工具不允许产出 final_answer新版本上线后效果变差prompt 或工具 schema 改动影响模型推理做 A/B 对比回放旧版本 trace 对比行为差异建立自动化回归集每次改 prompt 都跑一遍基础用例除了表里的内容我还想单独强调两条经验第一Agent 的错误处理不要靠“重新生成”硬扛。很多团队一遇到模型输出错误就简单粗暴地丢回给模型重新生成。如果第一次生成失败是因为 prompt 本身有歧义或上下文冲突重试多少次都一样会失败。真正有效的做法是“结构化重试”先分析失败原因再针对性地修正输入后重试。比如模型生成的 JSON 缺了一个字段那就在重试的 prompt 里面显式说明“你的 JSON 必须包含 field X”如果模型因为上下文太长而忽略指令那就先做上下文压缩再重试。这种有条件的重试成功率远高于盲目重试。第二Agent 的回归测试必须在编码阶段就建立。我在项目里维护了一个“agent regression suite”里面大概有 50~100 条典型任务覆盖常见场景和容易跑偏的情况。每次改 prompt、改工具调用逻辑、升级模型版本都要先把这一套用例跑完对比新旧版本的输出质量和完成率。没有这套回归模型一升级你可能是在不知不觉中把系统的稳定性交出去了。7. Harness 工程在未来 Agent 系统中的走向Harness 工程这套思路以后大概率会成为 Agent 开发的基础设施标配就像当年 Spring 之于 Java、React 之于前端一样从“加分项”变成“基本功”。我观察到的一个明显趋势是工具链正在把 Harness 的很多能力标准化和框架化LangGraph 原生支持循环控制LlamaIndex 内置了结构化输出解析各种 Agent 可观测性平台也在快速成熟。但框架只能帮你省掉“重复造轮子”的时间真正决定一个 Agent 系统质量高低的依然是你对以下几个问题的理解深度如何设计状态流才能让 Agent 的每一步都是可验证的如何平衡模型自主性和系统可控性如何在“让模型更聪明”和“让系统更稳定”之间做取舍。这些不会因为框架变了就过时它们是 Agent 系统设计的底层问题。在这个方向上我判断下面三个点会成为下一阶段的竞争焦点评估体系。Agent 的质量不能只靠“看着差不多”需要一整套自动化的评估方式。包括任务完成率、路径有效率、token 利用率、错误恢复率这些可量化指标配合基于 LLM 的裁判打分体系形成一套可以快速迭代的 Agent 质量闭环。多 Agent 协作的统一调度。当任务复杂到单个 Agent 搞不定时多个 Agent 的协作编排会成为刚需。谁负责任务拆解、谁负责质量审计、谁负责冲突消解这些角色的边界和互动协议本质上还是 Harness 工程在多 Agent 场景下的延伸。代码 Agent 的工具化沉淀。像 CLAUDE Code 这类编码 Agent本身就是 Harness 工程的一种极致应用通过给模型装备“搜索代码、读文件、执行测试、修改文件”的工具集配上一套严格的循环控制把编程任务从“生成代码”变成“驱动代码变更的闭环”。这类工具里沉淀下来的一些模式比如失败自动定位、测试驱动修改、小步提交反过来也能给我们做通用业务 Agent 提供不少参考。8. 结语稳定性的终点是系统设计做 Agent 快两年我越来越确定一件事模型的能力决定了 Agent 的天花板但 Harness 工程决定了 Agent 的地板在哪里。产品能不能上线用户敢不敢把重要的任务交给一个 Agent靠的不是模型偶尔的灵光一现而是整套系统在长时间、多用户、复杂输入下的一致性表现。我在实际项目里的体会是花在 Harness 上的时间从来不会白费。你多写一段校验逻辑、多埋一个 trace 点、多配一层预算熔断用户感知不到但它们都在默默阻止那些让 Agent 从“工具”变成“玩具”的致命事故。在这些机制都到位之前先别急着把 Agent 的“自主权”拉满稳住基本盘比追求炫酷的动作重要得多。最后再分享一个我自己一直坚持的工作习惯给 Agent 的每一步运行都留“后悔药”。任何一次工具调用、任何一次最终答复都要能在 trace 里回放、能在逻辑上解释、能被人为干预终止。一个随时可以“踩刹车”的 Agent才有可能真正上得了生产的牌桌。如果你正在搭建自己的 Agent 系统希望这篇梳理能帮你少踩几个我之前踩过的坑。稳定性的问题从来不是某一个点上的爆发而是一连串小细节的累积把这些细节一个一个焊死Agent 才会真正变得可靠。欢迎在实践中遇到具体问题时回来交流咱们下次聊聊更细的评估体系和自动化回归。