1. 从能跑到跑得稳AI Agent 的稳定性困局到底卡在哪很多人第一次搭 AI Agent 的时候都会经历一个极其相似的曲线Demo 阶段惊艳接入真实任务后崩溃。你让它查个资料、调个接口、写段代码单轮对话里它表现得像个天才可一旦任务链条拉长到七八步或者需要它自己判断下一步该干什么它就开始胡言乱语、重复劳动、忘记前面做过什么甚至凭空捏造一个根本不存在的工具去调用。这个现象背后其实不是模型不够聪明而是缺少一层工程化的驾驭结构。这也是最近 Harness 这个词频繁出现在 Agent 开发讨论里的原因。Harness 直译是马具、挽具它的隐喻非常准确模型是一匹力气很大但方向感不稳定的马Harness 就是套在它身上、让它能沿着既定路线稳定输出的那套约束与传导系统。我先把结论摆在前面方便你判断这篇内容是否对你有用Harness 不是提示词模板也不是某个具体框架而是一整套围绕 Agent 运行时的工程机制它负责上下文怎么组织、工具怎么暴露、状态怎么保存、失败怎么恢复、输出怎么校验。提示词工程解决的是这一轮怎么问Harness 工程解决的是整个任务生命周期怎么稳。这篇内容适合三类人一是已经写过能跑通的 Agent Demo、但被稳定性折磨过的开发者二是正在选型 Agent 框架、想搞清楚框架和Harness边界的技术负责人三是想系统理解 Agent 工程化、而不是停留在调 API 层面的学习者。我会从核心机制讲到落地实践把那些文档里不写、但实际踩过才知道的细节都摊开说。需要先厘清一个高频混淆点Harness 和 Agent 框架不是一回事。框架比如各种编排库更多提供的是积木告诉你有哪些组件可以拼Harness 更像是装配线和质检流程它规定了这些积木在运行时如何被调度、被约束、被观测。你可以用一个很轻的框架但配一套很重的 Harness也可以反过来。理解这个区分后面所有的设计取舍都会清晰很多。2. Harness 的四大核心机制拆解2.1 上下文管理不是塞得越多越好而是该忘的必须忘上下文管理是 Harness 里最容易被低估、也最容易翻车的部分。新手最常见的做法是把所有历史消息一股脑塞进 context觉得信息越全模型越聪明。实测下来恰恰相反上下文越长模型的注意力越涣散关键信息越容易被淹没而且 token 成本线性上涨延迟也跟着涨。一个成熟的 Harness 在上下文层面通常做三件事。第一是分层把上下文拆成系统指令层、任务状态层、近期交互层、长期记忆层不同层有不同的更新频率和裁剪策略。第二是压缩对早期的对话做摘要保留结论和关键决策丢掉冗余的来回。第三是检索不是所有历史都常驻上下文而是按需从外部存储里捞回来。这里有个我踩过的坑值得展开说。早期我做任务型 Agent 时把工具调用的完整返回结果比如一整页 JSON原样塞回上下文结果模型在后续推理里被这些噪声带偏开始纠结一些无关字段。后来改成只回填结构化摘要 关键字段稳定性立刻上了一个台阶。这个改动看起来小但它本质上是 Harness 在替模型做信息过滤而这正是模型自己做不到的。关于 token 的常见疑问也顺带说清楚Agent 场景下的 token 消耗远高于普通对话因为每一轮都要把系统指令、工具定义、历史状态重新送进去。一个五步任务实际 token 消耗可能是单轮对话的十几倍。所以 Harness 里必须有一个预算控制机制设定单任务 token 上限超了就触发压缩或终止否则很容易在长任务上烧出意外成本。2.2 工具编排与调用约束给模型的能力要刚刚好工具是 Agent 的手脚但给多了、给杂了反而会害了它。我见过一个 Agent 挂了二十多个工具结果模型在选择时频繁选错明明该用搜索却去调了计算器。这不是模型笨而是选择空间过大导致的决策质量下降。Harness 在工具层面的核心思路是按场景动态暴露工具集而不是一次性全给。比如任务处于信息收集阶段就只暴露搜索和读取类工具进入执行阶段再切换到写入和调用类工具。这种动态收窄能显著降低误调用率。另一个关键点是调用参数的校验与兜底。模型生成的工具参数经常有格式问题该传数组传了字符串、该传枚举值传了个近义词、必填字段漏了。如果直接把这些参数丢给真实接口轻则报错重则产生副作用比如误删数据。所以 Harness 必须在工具执行前加一层参数校验和规范化校验不过就把错误信息回传给模型让它重试而不是让整个任务崩掉。提示涉及写操作发消息、改数据、提交表单的工具务必在 Harness 层加确认或干跑机制。让模型先产出计划人工或规则确认后再真正执行这是防止 Agent 闯祸最有效的一道闸。2.3 状态与记忆让 Agent 记得住我是谁、我做到哪了长任务里Agent 失忆是常态。它可能在第 5 步忘了第 2 步已经确认过的用户偏好也可能重复执行已经完成的子任务。根因是状态没有被显式管理全靠上下文里那点历史撑着一旦被压缩就丢了。Harness 的做法是把状态外置成结构化数据而不是依赖模型记忆。典型的结构包括任务目标、已完成步骤、当前步骤、待办清单、关键变量比如用户 ID、文件路径、以及失败重试计数。这些状态在每一步结束后由 Harness 更新并在下一轮以精简形式注入上下文。记忆则分短期和长期。短期记忆就是当前任务的上下文任务结束即释放长期记忆是跨任务沉淀的用户偏好、领域知识、历史结论通常存在外部存储里按相关性检索注入。这里有个经验长期记忆的写入要克制。什么都记等于什么都没记检索时噪声太大。我一般只让 Agent 写入被验证过的、可复用的结论而不是过程性的碎碎念。2.4 失败恢复与循环控制Agent 最需要的其实是刹车Agent 最危险的行为不是答错而是陷入死循环反复调用同一个工具、反复重试同一个失败操作、在两个方案之间来回横跳。没有 Harness 约束的话它能一直转到 token 烧完或者你手动掐断。所以 Harness 必须内置几道刹车。第一是步数上限单任务最多执行 N 步超了就强制收尾并汇报。第二是重复检测如果连续几步的工具调用和参数高度相似判定为循环触发策略切换或终止。第三是失败重试上限同一个操作失败超过 K 次就放弃并记录而不是无限重试。失败恢复还涉及断点续跑。一个跑了很久的任务中途因为网络或接口问题中断如果状态是外置的就能从断点恢复而不是从头再来。这一点在成本敏感的场景里价值极高。我做过一个批量处理任务加上断点续跑后因为偶发失败导致的重跑成本直接降了大半。3. 提示词工程在 Harness 里的真实位置3.1 提示词不是主角而是 Harness 的一个受控组件很多人把 Agent 稳定性问题归因到提示词没写好于是反复打磨那段系统指令。提示词当然重要但在 Harness 视角下它只是众多受控组件之一而且它的效果高度依赖上下文和工具环境。同一段提示词在工具集精简、状态清晰的 Harness 里表现很好在工具混乱、上下文爆炸的环境里照样拉胯。我的实践体会是提示词负责定基调Harness 负责保执行。提示词里写清楚角色、目标、输出格式、边界约束就够了不要试图用提示词去解决本该由工程机制解决的问题。比如不要重复调用工具这种要求写在提示词里模型经常忘但用 Harness 的重复检测去硬约束就稳得多。3.2 结构化输出让模型的话能被程序读懂Agent 要和程序协作输出就必须可解析。Harness 里通常会强制模型按固定结构输出比如一个包含思考、动作、参数的 JSON。这样做的好处是程序能稳定地提取下一步动作而不是去猜一段自然语言里到底想干嘛。但结构化输出有个常见坑模型偶尔会输出不合法 JSON比如多一个逗号、少一个引号。所以 Harness 必须配一个解析容错层解析失败时不是直接报错而是把错误信息回传让模型重新生成一次。实测这个重试机制能救回绝大多数格式问题。3.3 提示词版本管理别让改一句变成玄学提示词一改Agent 行为可能大变这是常态。如果没有版本管理你根本不知道是哪次改动导致了效果波动。Harness 工程里应该把提示词当作代码资产来管理纳入版本控制、记录每次变更、配套回归测试。我一般会维护一组固定的测试任务每次改提示词或改 Harness 机制后都跑一遍看通过率和稳定性有没有退化。这套回归测试不需要很复杂十几个覆盖典型场景的用例就够用但它能帮你挡住大部分改一处崩一片的事故。4. 从零搭一个最小可用 Harness 的实操路径4.1 先定边界这个 Agent 到底要干什么、不能干什么动手写代码前先把边界想清楚。要明确三件事任务范围它负责哪类任务、能力边界它能调用哪些工具、能产生哪些副作用、终止条件什么情况下算完成、什么情况下必须停。这三件事定不下来后面所有机制都是空中楼阁。我习惯用一句话描述任务目标再列出允许的动作和禁止的动作两张清单。这个动作看似简单但它能逼你把模糊需求变成可执行约束。很多 Agent 不稳定根子上是需求本身就模糊模型只能靠猜。4.2 搭骨架状态机 工具层 上下文层最小可用的 Harness 不需要多复杂三个模块就能跑起来。状态机负责管理任务流转当前在哪一步、下一步去哪工具层负责工具的注册、校验、执行和结果回填上下文层负责组装每一轮送给模型的信息。用伪代码表达大概是这样class Harness: def __init__(self, tools, max_steps15): self.state {goal: None, done: [], current: None, retries: {}} self.tools tools self.max_steps max_steps def run(self, goal): self.state[goal] goal for step in range(self.max_steps): context self.build_context() action self.llm_decide(context) if action[type] finish: return action[result] result self.execute_tool(action) self.update_state(action, result) return self.force_wrap_up()这段骨架的价值在于所有关键控制点都是显式的。步数、状态更新、工具执行都在你的掌控里而不是交给模型自由发挥。4.3 加护栏把踩过的坑变成机制骨架跑通后就是不断加护栏的过程。每遇到一次翻车就问自己这个坑能不能变成一条 Harness 规则比如遇到重复调用就加重复检测遇到参数错误就加校验层遇到上下文爆炸就加压缩策略。Harness 的成熟度本质上就是踩坑经验的代码化程度。这里要提醒一点护栏不要一次加太多。每加一条都要能说清楚它防的是什么问题否则机制会越来越臃肿反而增加维护成本和调试难度。我一般遵循先复现问题、再加护栏、再验证有效的节奏。4.4 观测与日志看不见的 Agent 没法优化Agent 出问题时如果没有详细日志你根本不知道它当时看到了什么上下文、做了什么决策、调了什么工具。所以从第一天起就要把每一步的输入输出完整记录下来送给模型的上下文、模型的原始输出、工具调用参数、工具返回、状态变化。这些日志不只是排错用更是优化的依据。我经常通过翻日志发现某些失败其实是上下文里混入了无关信息或者某个工具的描述写得有歧义。日志是 Harness 的眼睛没有它所有优化都是盲猜。5. 那些文档不写、但实际会咬人的坑5.1 工具描述写得太聪明模型反而不会用工具描述是给模型看的不是给人看的。我见过把工具描述写得像产品文案的一堆形容词结果模型抓不住重点。正确做法是描述里明确写清楚这个工具干什么、什么时候用、参数是什么格式、返回什么。越直白越好别玩文字游戏。还有一个细节工具名和参数名要语义清晰。process_data这种名字模型很难判断该不该用extract_invoice_fields就明确得多。命名上的投入回报率比你想的高。5.2 上下文压缩压掉了关键约束压缩上下文时最容易犯的错是把约束条件也压没了。比如用户一开始说预算不超过 500压缩后这条没了Agent 后面就开始推荐超预算方案。所以压缩策略要区分信息类型结论、约束、关键变量必须保留过程性的来回可以丢。我的做法是给状态里的关键字段打标记压缩时这些字段永远保留其余按时间衰减。这样既省 token又不丢关键信息。5.3 重试机制反而放大了副作用重试是个好东西但对有副作用的操作要格外小心。如果一次发送消息因为超时被判定失败而重试可能实际已经发出去了重试就变成发了两条。所以 Harness 里要区分幂等操作和非幂等操作非幂等的重试必须配合去重或状态确认。注意涉及外部副作用的工具重试前一定要先确认上一次是否真的失败了而不是盲目重试。5.4 多 Agent 协作时的状态同步地狱当任务复杂到需要多个 Agent 分工时状态同步会变成新的噩梦。两个 Agent 各自维护一份状态很容易出现认知不一致A 以为任务完成了B 还在等 A 的结果。解决思路是状态集中管理所有 Agent 读写同一份权威状态而不是各存各的。另外多 Agent 之间的通信要结构化别用自然语言互相喊话否则信息在传递中会失真。用明确的任务对象和结果对象来交换稳定性会好很多。6. 关于选型与学习路线的一点个人判断聊到选型我的观点可能和主流不太一样别一上来就追求重型框架。很多框架功能很全但抽象层太厚出问题时你根本不知道是哪一层挂了。对于大多数团队从一个轻量骨架起步把 Harness 的核心机制自己实现一遍反而更容易掌控也更能理解每个机制存在的意义。学习路线上我建议按这个顺序走先理解 Agent 的基本循环决策-执行-观察再动手实现一个最小 Harness然后逐个加上上下文管理、工具校验、状态外置、失败恢复这些机制每加一个都配一个能复现的问题场景。这样学下来你得到的不只是会用某个框架而是知道为什么需要这些机制。至于那些热门的 Agent 架构讨论我的态度是架构是结果不是起点。先把手上的任务跑稳架构会随着你对问题的理解自然演化出来。硬套一个复杂架构往往是把简单问题复杂化。最后分享一个我反复验证过的心得Agent 的稳定性八成来自 Harness两成来自模型。与其不停换更强的模型不如先把 Harness 的护栏搭扎实。模型会迭代但一套好的 Harness 机制能让你在换任何模型时都保持稳定。这个投入长期看是最划算的。
1. 从能跑到跑得稳AI Agent 的稳定性困局到底卡在哪很多人第一次搭 AI Agent 的时候都会经历一个极其相似的曲线Demo 阶段惊艳接入真实任务后崩溃。你让它查个资料、调个接口、写段代码单轮对话里它表现得像个天才可一旦任务链条拉长到七八步或者需要它自己判断下一步该干什么它就开始胡言乱语、重复劳动、忘记前面做过什么甚至凭空捏造一个根本不存在的工具去调用。这个现象背后其实不是模型不够聪明而是缺少一层工程化的驾驭结构。这也是最近 Harness 这个词频繁出现在 Agent 开发讨论里的原因。Harness 直译是马具、挽具它的隐喻非常准确模型是一匹力气很大但方向感不稳定的马Harness 就是套在它身上、让它能沿着既定路线稳定输出的那套约束与传导系统。我先把结论摆在前面方便你判断这篇内容是否对你有用Harness 不是提示词模板也不是某个具体框架而是一整套围绕 Agent 运行时的工程机制它负责上下文怎么组织、工具怎么暴露、状态怎么保存、失败怎么恢复、输出怎么校验。提示词工程解决的是这一轮怎么问Harness 工程解决的是整个任务生命周期怎么稳。这篇内容适合三类人一是已经写过能跑通的 Agent Demo、但被稳定性折磨过的开发者二是正在选型 Agent 框架、想搞清楚框架和Harness边界的技术负责人三是想系统理解 Agent 工程化、而不是停留在调 API 层面的学习者。我会从核心机制讲到落地实践把那些文档里不写、但实际踩过才知道的细节都摊开说。需要先厘清一个高频混淆点Harness 和 Agent 框架不是一回事。框架比如各种编排库更多提供的是积木告诉你有哪些组件可以拼Harness 更像是装配线和质检流程它规定了这些积木在运行时如何被调度、被约束、被观测。你可以用一个很轻的框架但配一套很重的 Harness也可以反过来。理解这个区分后面所有的设计取舍都会清晰很多。2. Harness 的四大核心机制拆解2.1 上下文管理不是塞得越多越好而是该忘的必须忘上下文管理是 Harness 里最容易被低估、也最容易翻车的部分。新手最常见的做法是把所有历史消息一股脑塞进 context觉得信息越全模型越聪明。实测下来恰恰相反上下文越长模型的注意力越涣散关键信息越容易被淹没而且 token 成本线性上涨延迟也跟着涨。一个成熟的 Harness 在上下文层面通常做三件事。第一是分层把上下文拆成系统指令层、任务状态层、近期交互层、长期记忆层不同层有不同的更新频率和裁剪策略。第二是压缩对早期的对话做摘要保留结论和关键决策丢掉冗余的来回。第三是检索不是所有历史都常驻上下文而是按需从外部存储里捞回来。这里有个我踩过的坑值得展开说。早期我做任务型 Agent 时把工具调用的完整返回结果比如一整页 JSON原样塞回上下文结果模型在后续推理里被这些噪声带偏开始纠结一些无关字段。后来改成只回填结构化摘要 关键字段稳定性立刻上了一个台阶。这个改动看起来小但它本质上是 Harness 在替模型做信息过滤而这正是模型自己做不到的。关于 token 的常见疑问也顺带说清楚Agent 场景下的 token 消耗远高于普通对话因为每一轮都要把系统指令、工具定义、历史状态重新送进去。一个五步任务实际 token 消耗可能是单轮对话的十几倍。所以 Harness 里必须有一个预算控制机制设定单任务 token 上限超了就触发压缩或终止否则很容易在长任务上烧出意外成本。2.2 工具编排与调用约束给模型的能力要刚刚好工具是 Agent 的手脚但给多了、给杂了反而会害了它。我见过一个 Agent 挂了二十多个工具结果模型在选择时频繁选错明明该用搜索却去调了计算器。这不是模型笨而是选择空间过大导致的决策质量下降。Harness 在工具层面的核心思路是按场景动态暴露工具集而不是一次性全给。比如任务处于信息收集阶段就只暴露搜索和读取类工具进入执行阶段再切换到写入和调用类工具。这种动态收窄能显著降低误调用率。另一个关键点是调用参数的校验与兜底。模型生成的工具参数经常有格式问题该传数组传了字符串、该传枚举值传了个近义词、必填字段漏了。如果直接把这些参数丢给真实接口轻则报错重则产生副作用比如误删数据。所以 Harness 必须在工具执行前加一层参数校验和规范化校验不过就把错误信息回传给模型让它重试而不是让整个任务崩掉。提示涉及写操作发消息、改数据、提交表单的工具务必在 Harness 层加确认或干跑机制。让模型先产出计划人工或规则确认后再真正执行这是防止 Agent 闯祸最有效的一道闸。2.3 状态与记忆让 Agent 记得住我是谁、我做到哪了长任务里Agent 失忆是常态。它可能在第 5 步忘了第 2 步已经确认过的用户偏好也可能重复执行已经完成的子任务。根因是状态没有被显式管理全靠上下文里那点历史撑着一旦被压缩就丢了。Harness 的做法是把状态外置成结构化数据而不是依赖模型记忆。典型的结构包括任务目标、已完成步骤、当前步骤、待办清单、关键变量比如用户 ID、文件路径、以及失败重试计数。这些状态在每一步结束后由 Harness 更新并在下一轮以精简形式注入上下文。记忆则分短期和长期。短期记忆就是当前任务的上下文任务结束即释放长期记忆是跨任务沉淀的用户偏好、领域知识、历史结论通常存在外部存储里按相关性检索注入。这里有个经验长期记忆的写入要克制。什么都记等于什么都没记检索时噪声太大。我一般只让 Agent 写入被验证过的、可复用的结论而不是过程性的碎碎念。2.4 失败恢复与循环控制Agent 最需要的其实是刹车Agent 最危险的行为不是答错而是陷入死循环反复调用同一个工具、反复重试同一个失败操作、在两个方案之间来回横跳。没有 Harness 约束的话它能一直转到 token 烧完或者你手动掐断。所以 Harness 必须内置几道刹车。第一是步数上限单任务最多执行 N 步超了就强制收尾并汇报。第二是重复检测如果连续几步的工具调用和参数高度相似判定为循环触发策略切换或终止。第三是失败重试上限同一个操作失败超过 K 次就放弃并记录而不是无限重试。失败恢复还涉及断点续跑。一个跑了很久的任务中途因为网络或接口问题中断如果状态是外置的就能从断点恢复而不是从头再来。这一点在成本敏感的场景里价值极高。我做过一个批量处理任务加上断点续跑后因为偶发失败导致的重跑成本直接降了大半。3. 提示词工程在 Harness 里的真实位置3.1 提示词不是主角而是 Harness 的一个受控组件很多人把 Agent 稳定性问题归因到提示词没写好于是反复打磨那段系统指令。提示词当然重要但在 Harness 视角下它只是众多受控组件之一而且它的效果高度依赖上下文和工具环境。同一段提示词在工具集精简、状态清晰的 Harness 里表现很好在工具混乱、上下文爆炸的环境里照样拉胯。我的实践体会是提示词负责定基调Harness 负责保执行。提示词里写清楚角色、目标、输出格式、边界约束就够了不要试图用提示词去解决本该由工程机制解决的问题。比如不要重复调用工具这种要求写在提示词里模型经常忘但用 Harness 的重复检测去硬约束就稳得多。3.2 结构化输出让模型的话能被程序读懂Agent 要和程序协作输出就必须可解析。Harness 里通常会强制模型按固定结构输出比如一个包含思考、动作、参数的 JSON。这样做的好处是程序能稳定地提取下一步动作而不是去猜一段自然语言里到底想干嘛。但结构化输出有个常见坑模型偶尔会输出不合法 JSON比如多一个逗号、少一个引号。所以 Harness 必须配一个解析容错层解析失败时不是直接报错而是把错误信息回传让模型重新生成一次。实测这个重试机制能救回绝大多数格式问题。3.3 提示词版本管理别让改一句变成玄学提示词一改Agent 行为可能大变这是常态。如果没有版本管理你根本不知道是哪次改动导致了效果波动。Harness 工程里应该把提示词当作代码资产来管理纳入版本控制、记录每次变更、配套回归测试。我一般会维护一组固定的测试任务每次改提示词或改 Harness 机制后都跑一遍看通过率和稳定性有没有退化。这套回归测试不需要很复杂十几个覆盖典型场景的用例就够用但它能帮你挡住大部分改一处崩一片的事故。4. 从零搭一个最小可用 Harness 的实操路径4.1 先定边界这个 Agent 到底要干什么、不能干什么动手写代码前先把边界想清楚。要明确三件事任务范围它负责哪类任务、能力边界它能调用哪些工具、能产生哪些副作用、终止条件什么情况下算完成、什么情况下必须停。这三件事定不下来后面所有机制都是空中楼阁。我习惯用一句话描述任务目标再列出允许的动作和禁止的动作两张清单。这个动作看似简单但它能逼你把模糊需求变成可执行约束。很多 Agent 不稳定根子上是需求本身就模糊模型只能靠猜。4.2 搭骨架状态机 工具层 上下文层最小可用的 Harness 不需要多复杂三个模块就能跑起来。状态机负责管理任务流转当前在哪一步、下一步去哪工具层负责工具的注册、校验、执行和结果回填上下文层负责组装每一轮送给模型的信息。用伪代码表达大概是这样class Harness: def __init__(self, tools, max_steps15): self.state {goal: None, done: [], current: None, retries: {}} self.tools tools self.max_steps max_steps def run(self, goal): self.state[goal] goal for step in range(self.max_steps): context self.build_context() action self.llm_decide(context) if action[type] finish: return action[result] result self.execute_tool(action) self.update_state(action, result) return self.force_wrap_up()这段骨架的价值在于所有关键控制点都是显式的。步数、状态更新、工具执行都在你的掌控里而不是交给模型自由发挥。4.3 加护栏把踩过的坑变成机制骨架跑通后就是不断加护栏的过程。每遇到一次翻车就问自己这个坑能不能变成一条 Harness 规则比如遇到重复调用就加重复检测遇到参数错误就加校验层遇到上下文爆炸就加压缩策略。Harness 的成熟度本质上就是踩坑经验的代码化程度。这里要提醒一点护栏不要一次加太多。每加一条都要能说清楚它防的是什么问题否则机制会越来越臃肿反而增加维护成本和调试难度。我一般遵循先复现问题、再加护栏、再验证有效的节奏。4.4 观测与日志看不见的 Agent 没法优化Agent 出问题时如果没有详细日志你根本不知道它当时看到了什么上下文、做了什么决策、调了什么工具。所以从第一天起就要把每一步的输入输出完整记录下来送给模型的上下文、模型的原始输出、工具调用参数、工具返回、状态变化。这些日志不只是排错用更是优化的依据。我经常通过翻日志发现某些失败其实是上下文里混入了无关信息或者某个工具的描述写得有歧义。日志是 Harness 的眼睛没有它所有优化都是盲猜。5. 那些文档不写、但实际会咬人的坑5.1 工具描述写得太聪明模型反而不会用工具描述是给模型看的不是给人看的。我见过把工具描述写得像产品文案的一堆形容词结果模型抓不住重点。正确做法是描述里明确写清楚这个工具干什么、什么时候用、参数是什么格式、返回什么。越直白越好别玩文字游戏。还有一个细节工具名和参数名要语义清晰。process_data这种名字模型很难判断该不该用extract_invoice_fields就明确得多。命名上的投入回报率比你想的高。5.2 上下文压缩压掉了关键约束压缩上下文时最容易犯的错是把约束条件也压没了。比如用户一开始说预算不超过 500压缩后这条没了Agent 后面就开始推荐超预算方案。所以压缩策略要区分信息类型结论、约束、关键变量必须保留过程性的来回可以丢。我的做法是给状态里的关键字段打标记压缩时这些字段永远保留其余按时间衰减。这样既省 token又不丢关键信息。5.3 重试机制反而放大了副作用重试是个好东西但对有副作用的操作要格外小心。如果一次发送消息因为超时被判定失败而重试可能实际已经发出去了重试就变成发了两条。所以 Harness 里要区分幂等操作和非幂等操作非幂等的重试必须配合去重或状态确认。注意涉及外部副作用的工具重试前一定要先确认上一次是否真的失败了而不是盲目重试。5.4 多 Agent 协作时的状态同步地狱当任务复杂到需要多个 Agent 分工时状态同步会变成新的噩梦。两个 Agent 各自维护一份状态很容易出现认知不一致A 以为任务完成了B 还在等 A 的结果。解决思路是状态集中管理所有 Agent 读写同一份权威状态而不是各存各的。另外多 Agent 之间的通信要结构化别用自然语言互相喊话否则信息在传递中会失真。用明确的任务对象和结果对象来交换稳定性会好很多。6. 关于选型与学习路线的一点个人判断聊到选型我的观点可能和主流不太一样别一上来就追求重型框架。很多框架功能很全但抽象层太厚出问题时你根本不知道是哪一层挂了。对于大多数团队从一个轻量骨架起步把 Harness 的核心机制自己实现一遍反而更容易掌控也更能理解每个机制存在的意义。学习路线上我建议按这个顺序走先理解 Agent 的基本循环决策-执行-观察再动手实现一个最小 Harness然后逐个加上上下文管理、工具校验、状态外置、失败恢复这些机制每加一个都配一个能复现的问题场景。这样学下来你得到的不只是会用某个框架而是知道为什么需要这些机制。至于那些热门的 Agent 架构讨论我的态度是架构是结果不是起点。先把手上的任务跑稳架构会随着你对问题的理解自然演化出来。硬套一个复杂架构往往是把简单问题复杂化。最后分享一个我反复验证过的心得Agent 的稳定性八成来自 Harness两成来自模型。与其不停换更强的模型不如先把 Harness 的护栏搭扎实。模型会迭代但一套好的 Harness 机制能让你在换任何模型时都保持稳定。这个投入长期看是最划算的。
