同一份数据，两个Agent给出截然不同的结论，商家质疑、老板震怒。多智能体狂热退潮后，单Agent+Harness架构成为新方向。本文从实战出发，拆解Harness三层架构，探讨产品经理如何在不确定性中守住输出一致性的底线。

不知道你有没有遇到过，同一份数据同一个Skill给到部门内不同的Agent合作方，结果大相径庭。

A 团队告诉商户“你的酒店上周入住率 76.3%，环比上涨 2.1%”，B 团队对同一个商户说“近期入住表现不错，高于市场平均”。

一个给了精确数字，一个给了模糊感受。

于是商家截图发到群里：同一个系统的不同入口，答案怎么就不一样了？

老板们在不清楚工程细节的背景下，严令要求数据和结论的一致性，没得商量。

这就是我过去几个月的日常。这局面究竟怎么发生的，从头说起。

一、钟摆：多Agent是未来 vs 单Agent就够了

坦白说，前两年我也追过多智能体的风。

那阵子全行业都在拆Agent。CrewAI 刚发布，LangGraph 支持多智能体编排，VC 疯狂投多 Agent 赛道，社区里每天都在讨论怎么拆更优雅。

我们团队也不例外，秉承着分层分模块的思路，把商家智能场景拆成查询 Agent、诊断 Agent、操作Agent，基于业务领域或能力领域划分不同Agent的职责边界。当时我更新的文章AI系列（四）：一个案例讲透多智能体应用还在为自己设计的多智能体架构沾沾自喜，自认为每个Agent 职责单一可独立迭代，分到每个合作方都有肉吃。

“分层分模块”，听着耳熟吧？

这俨然是软件工程的经典条件反射。多智能体刚好满足了这种直觉，让很多团队庆幸终于可以用熟悉的方式搞 AI 了。

但故事的后半段你也知道。

跨Agent 之间的通信开始丢语义。A 说“用户情绪激动”，B 不知道该道歉还是该转人工；状态同步出 bug，诊断 Agent 拿到的数据和查询 Agent 实际返回的对不上；调试一个 case 要翻三个 Agent 的日志才能定位问题在哪。

Google Research 一篇关于多智能体规模化的研究发现，Agent 间的交互轮数随数量增长遵循 n^1.724 的幂律：3 个 Agent 的交互开销是 1 个的 6 倍，5 个就是 15 倍。

花了大半年时间，我终于走不动了。

哭笑不得的是，今年年初开始，风向变了。模型能力跨过临界点，单个模型的上下文窗口和工具调用能力大幅提升。OpenClaw、Hermes 用事实证明，一个 Agent 叠加一堆工具和技能就能搞定大多数任务。你随便去看一款智能体产品，无论是办公、娱乐、代码等领域，纷纷开始树立智能体生态人设，打造开放共建的Skill和MCP市场。社区里那些最早鼓吹“多 Agent 是未来”的人，开始用力地鼓吹“单 Agent + 多 Skill 才是正道”。

换了旗帜，但冲锋的姿势一模一样。

我们团队也跟着回摆了。

我试图把三个Agent 合回一个，能力拆成 Skill 挂载，用 MCP 做标准化接入。的确，单 Agent 的调试成本降了一个数量级，维护终于不靠英雄主义了。但由于涉及多方研发团队，牵一发而动全身，于是我再三评估后决定，保留原多智能体架构作为即刻响应商户的快速模式，预测性强、可被验证的确定性流水线能力，顾全商户在感知上有个确定性的兜底，满足商户日常问答和快捷操作的需要；增设专家模式，基于AI native动态编排引擎，探一探单Agent自主编排的底线和上限，允许更多不确定性但换取更深洞察的服务场景，给出更专业的诊断分析和创意生成。

悬着的一颗心刚落，新的问题跟着来了。

公司开始搞赛马，大家都在摸着石头过河，多个团队各自做Agent，接同一批Skill 和 MCP 工具。理论上，同样的工具+数据源，输出应该差不多。但现实是，两位厨师用了同一把菜刀，一个做出了手握寿司，一个做出了东北乱炖。

技术架构在变，组织协作方式在变，但无论如何，用户看到的应该是一致的、可信的输出。问题是：谁来保证这件事？怎么保证？

二、“让模型自己发挥”是个伪命题

在试图回答这个问题前，我想先拆掉一个认知障碍。

经常有老板要求：“不要让模型有过多发挥。”

一转头研发跟我说：“别定义那么多，你得给模型足够的发挥空间。”我问他模型什么时候会调这个工具、传什么参数、返回结果后会怎么组织话术，分段给还是打包整段输出……他说：“让模型自己决定。”

我追问：“那你怎么保证每次输出是一致的？”

他说：“不需要每次一致，AI Native 就是要允许涌现。”

涌现。

这个词我可太熟了。前几年被用来解释一切解释不了的东西不就是它吗？模型输出好了，叫涌现；输出离谱了，也叫涌现。涌现成了薛定谔的遮羞布，你打开盒子之前，它可能是惊喜，也可能是事故。

但产品经理不能活在薛定谔的世界里，尤其是在B端服务的确定性场景里。商户不关心涌现，他关心的是：我问了同一个问题，为什么你们两个入口给我的信息是矛盾的？

让模型自己发挥，翻译成工程语言就是：没有上下文管理策略，没有输出格式约束，没有结果校验机制。

换句话说，你不是给模型自由，你是什么都没给。

仔细想想，这个现象和上一轮多Agent 的狂热是同一种病。多 Agent 时期，很多人把架构先进等同于产品做得好；现在单 Agent 回潮了，另一群人又把“不约束模型”当成了AI Native的讯号。本质都一样，用技术叙事代替了对问题的判断。

在这种错误信号的指引下，身边的产品经理们开始怀疑，一个好的模型就足以达成目的，我是不是不用定义需求了？

三、模型提供智能，Harness提供控制

回到最基础的问题：Agent 到底是什么，哪些部分是模型负责的，哪些部分必须有人来设计？

Agent的经典定义还历历在目吧？

以大语言模型为大脑，通过规划来分解目标，利用记忆来保存状态，借助工具来突破边界，通过行动来影响环境。

规划、记忆、工具、行动，四要素朗朗上口。这个框架没错，但有一个问题，它是从模型视角出发的。规划是模型在规划，记忆是模型在调取，行动是模型在执行，工具是模型在调用。一切围着模型转。

图1: Agent=模型x（规划+记忆+工具+行动）

这会导致一个认知陷阱：既然模型什么都能干，那我把模型放进去，接上工具，不就是个Agent 了吗？

不开玩笑，太多人下意识是这个反应。

注意，模型和工具之间，还需要一整套控制结构：谁来决定何时调用哪个工具？出错了怎么兜底？多步任务之间的状态谁来管？输出格式谁来约束？

这套控制结构，有个名字：Harness工程。

Harness 这个概念在今年上半年被行业广泛讨论。Mitchell Hashimoto 最早明确定义了这个术语，随后 OpenAI、Anthropic 先后发文阐述，意思是模型之外的一切工程脚手架。

Agent = Model + Harness。模型提供智能，Harness 提供控制。

这个公式引发不少热议，相信你并不陌生。回过头看我自己的经历，确实如此。今年我们多Agent 拆了又合，问题不在模型数量，而在 Harness 的设计质量。Harness 设计得好，一个 Agent 就够；Harness 设计得烂，拆成十个 Agent 也是十倍的烂。

那Harness 里面到底有什么？

内业讨论 Harness 的文章已经够多了，几乎都在罗列“六个组件、八个模块、十个要素”，但我认为真正有价值的认知不在于有哪些组件，而在于这些组件之间的关系。毕竟Harness 不是一个单一组件，而是一个系统。这也是搭建一个真正好用的Agent如此困难的原因，你不是在调一个参数，你是在设计一整套工程架构。

与其列清单，不如看职责分工。我把它拆成三个上下游的协作层级：

• 最上面是编排层，相当于指挥官。任务拆解、步骤规划、错误恢复、循环控制、人机协作决策，它决定先做什么后做什么，出了问题怎么兜底。
• 中间是能力层，相当于参谋部。上下文组装、记忆检索、知识召回、Prompt 管理、上下文压缩，确保指挥官和模型在每一步都拿到正确的情报，而不是被无关信息淹没。
• 最下面是连接层，相当于外交部。MCP 工具调用、Skill 技能包、API 适配、沙箱执行、模型服务，它负责对接外部所有资源，把能力接进来，把结果送出去。

而模型本身，是这三层共同服务的大脑。

图2: Harness的三层架构

那之前常说的规划、记忆、行动、工具去哪了？

没有消失，只是被重新归位了。

• 规划，归入编排层。但编排层不只是规划，还包括错误恢复、循环控制、人机协作。模型负责“想”怎么规划，编排层负责“执行”这个规划。规划是模型的能力，编排是工程的落地。
• 记忆，归入能力层。但能力层不只是记忆，还包括上下文的组装和压缩。记忆只是上下文的来源之一，真正的工程挑战是：在有限的token 窗口里，把最相关的信息喂给模型，把不相关的果断扔掉。
• 工具，归入连接层。但连接层不只是工具，还包括Skill 技能包、模型服务本身和沙箱环境。工具是一个个零件，连接层负责把零件装上去，管好接口标准，处理调用异常。
• 行动，分散在这三层里。编排层决定“该不该行动”，能力层决定“带着什么信息去行动”，连接层负责“执行这个行动”。

为什么要重新划分？

来看一个具体场景。假设你给一个OTA 平台设计商家经营智能体，需求场景如下：接收商家在多个渠道（App、网页、微信）发来的消息，理解意图后规划执行步骤，调用价格查询、竞品分析、库存管理等十几个工具，再把中间结果存进记忆以备下次使用，最终把分析报告返给商家。

如果你直接选型一个大模型，按四要素拆模块：规划、记忆、工具、行动，你很快会碰壁。几个模块之间全是交叉依赖：规划需要读记忆，行动需要调工具，工具调用的结果要写回记忆，记忆的内容又要影响下一轮规划。四个模块互相调用，代码缠在一起，改一个地方要动三个模块。

“规划、记忆、行动、工具”描述的是模型在做什么，三层 Harness 描述的是工程上谁负责什么。前者是理解 Agent 原理的认知框架，后者是动手做 Agent 时的施工图纸。

你拿原理当图纸去施工，会发现某个模块到底谁写的、代码放在哪、出了 bug 谁改，全是糊涂账。模型是大脑，负责“想”，决定智能的下限；Harness是大脑之外的一切，负责把“想”变成“做”，决定智能的上限。二者组合，才能让Agent真正具备自主感知环境、做出决策、执行行动并从结果中学习的能力。

这个判断不只是理论推演，行业也在用脚投票。8月 DeepSeek Harness的开源，就是一个标志性事件。当一家模型层的标杆企业，把战略重心公开伸向Harness层，并选择用“Harness”作为产品命名时，它就向整个行业发出了一个信号：模型是地基，Harness才是建筑。模型公司不做Harness，就只能沦为别人架构里的一个可替换组件。

四、产品经理该管到哪一层？

概念对齐完毕。回到那个核心问题：同一个Skill，为什么两个 Agent 的输出能差这么多？

有了Harness三层的概念，答案已经呼之欲出了。

还记得开头那个入住率76.3% vs “表现不错”的故事吗？现在用Harness三层拆解下原因。

Skill 和 MCP 只是 Harness 里连接层的一个零件。两个团队接了同一个零件，但彼此的能力层和编排层完全不同。

在能力层，A 团队在调用 Skill 之前，注入了用户的店铺信息、历史偏好、当前对话摘要；B 团队什么都没注入，模型拿到的上下文里只有用户的query。同一台咖啡机，一个放了精品豆，一个放了速溶粉。

在编排层，A 团队的 Agent 会先查基础数据，确认数据完整后再调诊断 Skill，拿到结果还会做一轮合理性校验；B 团队的 Agent 直接把用户的问题丢给模型，模型想调什么调什么，调完就输出，没有校验。

在输出后的处理上，A 团队有标准话术模板，数值保留两位小数，空数据明确说“暂无数据”；B 团队让模型自由生成，今天说“表现不错”，明天可能说“有待提升”。

所以真相是：不一致的根源不在Skill，在 Skill 之上的两层。

Skill 是标准化的，能力层和编排层才是各团队的自留地。那么问题来了，这两层该放任各自为政，还是应该有人拉齐？

AI Native 时代最大的误解之一：既然模型能自己想、自己做，产品经理是不是可以歇歇了？

我的观点是：正是因为模型能自己想、自己做，产品经理才必须管得更深。

一个传统的API 接口，你定义好输入输出，对方照着调就行，输出是确定性的。但一个 Skill 被 Agent 调用时，中间有一个“会自己做决定的模型”。模型会决定什么时候调、传什么参数、拿到结果后怎么表达。这个决定过程受上下文影响，受 prompt 影响，受编排逻辑影响。

你提供的不是一个确定性的接口，而是一个嵌入了不确定性系统的组件。

所以产品要管的不只是Skill 本身，而是 Skill 的运行契约。用三层 Harness 的视角来说：

首先是连接层，你必须管到底。工具的name、description、参数枚举值、返回 schema，这些必须原样使用，不允许对方改写。因为模型对工具的理解完全依赖 description 的措辞，改一个词可能导致调用率从 90% 掉到 60%。这不是在开玩笑。

这一点在之前建设多Agent 时我就吃过亏。当时不同 Agent 各自定义了工具的描述格式，结果同一个工具在不同 Agent 里的调用行为完全不同。这回开设专家模式回归单 Agent 后，第一时间统一了 description 标准，调用准确率立刻回来了。在我定义的场景里，快速模式里工具调用是确定性流水线，契约天然被代码保障；专家模式里模型自主编排，契约就成了能不能信任输出的唯一防线。

其次是能力层，你必须定义契约。你不能替对方做上下文管理，但你可以定义调用这个 Skill 之前，上下文里必须包含什么。比如：必须有店铺 ID 和时间范围（否则查不了数据），推荐有用户历史偏好（有了输出更准），禁止注入超过 10 轮的完整对话历史（会导致注意力稀释）。

上下文注入契约，是输出一致性的最大杠杆。

最后是编排层，你必须给建议。复杂Skill 的调用通常会有前置依赖，比如必须先查到基础数据，才能调分析报告Skill。你需要把这些前置条件写清楚，作为调用工具前必须满足的条件清单。对方的 Agent 怎么编排是他的事，但前置条件不满足就调用，出来的结果你不背锅。

对产品而言，这三层管的深度不同：连接层必须强势管理，能力层定义好统一的契约，编排层可以提供建议。从管界面，变成了管契约。

那么，到此为止，够了吗？

你得让契约可验证。

传统 PRD 告诉工程师“做什么”，AI 时代的评测集告诉所有人“什么算做好了”。PRD 定义功能边界，评测集定义质量底线——评测就是新的 PRD。

不同于以往传统产品惯用的需求文档，你更要把模糊的用户反馈转化为可复现、可衡量的测试任务，让合作团队知道具体应该改进什么，并持续验证改进是否有效。

毕竟我们构建的产品高度不确定，位于模型、运行框架以及面向特定用户的一组上下文的交汇处。评测集不仅能帮助模型团队，也能帮助整个产品团队创造更好的用户体验，让一大群人朝同一方向划船。

道理说完了，拉回到现实。

回到赛马本身。老板让你评估两个团队的Agent 谁更好，怎么评？

绝大多数人的第一反应是：找几个case 试一试，看谁的回答更好。

坦白说，结论随你选的case 变化，这并不是一种科学的评估。

更合理的做法是，你得建立一套结构化的评估框架，顺着三层Harness 从下往上看：

第一层：连接层，看工具调得对不对

建一个黄金测试集，20 到 50 条标准测试用例，固定 query + 固定上下文，期望输出明确。跑一遍两个 Agent，对比：工具调用准确率，该调的调了没有？参数传对了没有？数值准确性，核心指标误差是否在 1% 以内？格式一致性，时间、数值、单位是否完整？

这一层的评估是客观的，有明确的对错。如果在这层就大量报错，后面不用看了。

第二层：能力层，看上下文用得好不好

同样的问题，分别在“上下文充分”和“上下文残缺”两种条件下测试。上下文充分时，两个 Agent 的输出差异有多大？上下文残缺时，Agent 是会追问补全信息，还是硬着头皮编造？

追问能力是一个被严重低估的指标。好的Agent 在信息不足时会说“请问您想了解哪个时间段的数据？”差的 Agent 会直接编一个时间段然后查出一堆无关数据，用户还以为是对的。

第三层：编排层，看复杂任务扛不扛得住

给一个需要3 到 5 步才能完成的任务，观察：步骤规划是否合理？有没有跳步或冗余步？中间某步出错后，是从头重来还是能从断点恢复？最终输出是否把多步结果合理整合，而非简单拼接？

编排能力的差距在简单问题上看不出来，差距会在复杂问题上指数级放大。

三层评完，你大概能判断谁更好。但还有一个问题值得追问：团队能不能解释清楚，自己为什么好？

能解释清楚系统行为的团队，才是真正理解自己在做什么的团队。说不清楚的，下次改版也不知道往哪改。

五、在变化里找到不变的东西

最后聊聊这两年来的感受。

2024年追多 Agent，2025年踩坑磨合，2026 年回摆单 Agent，这会儿又开始在赛马中做裁判。技术栈换了几轮，组织架构也在调整，合作方换了一茬又一茬。

两年过去，社区只是换了个名词在跑同一条路，我总在提醒自己要保持清醒。

你去看真正做得好的AI 产品，Claude 的 Computer Use、Cursor 的代码生成、Perplexity 的搜索，哪一个是跟着技术叙事跑的？它们做的事情出奇一致：在精确定义的边界内给模型最大的自由。Claude 有严格的 system prompt 和安全边界，Cursor 在每次代码生成前做精密的上下文裁剪，Perplexity 对搜索结果有明确的引用格式和事实校验。

自由和约束不是对立的。没有约束的自由叫混沌，有约束的自由叫智能。

产品经理在AI 时代的角色不是被削弱了，是换了一种形态。你不再写“点击按钮 A 跳转到页面 B”这种确定性流程，但你要定义：

• 上下文契约：模型在什么信息环境下工作；
• 输出边界：什么能说、什么不能说、数值精度到几位；
• 质量基线：一组可复现的测试用例和通过标准；
• 降级策略：模型不确定时该怎么办；
• 反馈闭环：上线后的bad case谁收集、谁定性、谁推动修复。

这些东西，不会有工程师主动帮你定义。哪些信息对用户重要？输出到什么程度算质量过关？不确定的时候是宁可说少还是宁可说多？

这是产品决策，不是技术判断。

过去两年，技术在摇摆，我也在摇摆。但直到今天，我越来越确信一件事：架构会变，模型会迭代，组织会重组。但“用户看到的事实性输出应该一致且可信”这件事，不会变。

我得守住这条线。

从跟着技术跑，转成在变化里找到不变的东西，然后守住它。这大概是AI 产品最该想明白的一件事。