别只给 AI 产品接模型：Agent 能做成事，靠的是策略和 Harness

AI 产品不只是接入模型。真正让 Agent 做成事的，是策略、交互、评测和 Harness 形成的运行闭环。>

导语

很多 AI 产品的第一版，都停在"把模型能力接进来"这一步。

用户输入一句话，系统给出一段回答；用户提出一个目标，Agent 生成一份计划。Demo 往往很好看，因为模型足够聪明，顺利路径也足够短。但一旦进入真实任务，麻烦会很快出现：用户没有说清楚约束，工具返回空结果，权限不够，任务做了一半目标变了，某个动作还有不可逆风险。

这时才会发现，AI 产品 的难点从来不只是"模型能不能回答"。真正的问题是：产品能不能让 Agent 在不确定环境里持续做判断，并且知道什么时候继续、什么时候停下、什么时候把控制权交还给人。

这正是策略和 Harness 的价值。

图：策略、交互、评测和 Harness 一起决定 Agent 能否完成真实任务

AI 产品的核心不是输出，而是任务完成

传统软件通常把路径写死：用户点击按钮，系统执行确定动作。AI 产品的路径更松散，用户表达的是目标，Agent 需要自己补全上下文、拆任务、调用工具、观察结果，再决定下一步。

所以一个成熟的 AI 产品，至少要同时经营三套能力：

能力	它回答的问题	产品侧真正要做的事
评测	结果是不是变好了	定义任务成功标准，构造真实任务集，观察失败模式，把结果反馈给模型、工具、提示词和策略
交互	用户敢不敢把任务交出去	设计任务入口、澄清方式、过程可见性、确认、撤销、接管和失败恢复
策略	Agent 该如何行动	决定何时追问、何时调用工具、哪些动作必须授权、什么情况停止、失败后怎样降级

可以把它看成一个任务闭环：

评测、交互、策略不是三个孤立模块，而是同一个任务成功闭环里的三种产品判断。没有评测，团队不知道改动是否真的有效；没有交互，用户不知道系统在做什么，也不敢把高风险任务交出去；没有策略，Agent 只是在调用模型，不一定能完成用户真正想完成的工作。

拿行业调研报告举例。用户看到的可能只是一个输入框和最终报告，但产品背后要做很多决定：报告怎样才算可用？来源是否可信？结论能不能追溯？行业、受众、篇幅和时效要不要追问？证据不足时能不能下判断？什么时候展示检索进度，什么时候请用户确认方向？

这些问题没有一个能靠"模型更强一点"自动消失。

评测不是分数系统，而是产品的判断系统

AI 产品里最容易被误解的评测，是把它做成一个模型排行榜。回答像不像、分数高不高，当然可以参考，但产品真正关心的是任务有没有完成。

"帮用户完成一次报销"不是生成一段说明，而是信息是否齐全、规则是否满足、流程是否提交成功、用户是否还要返工。"帮用户写一份报告"也不是把字数凑够，而是问题是否覆盖、证据是否可靠、结论是否能支撑决策。

因此评测要贴着真实任务设计：

· 高频任务要覆盖，边界案例也要覆盖。

· 顺利样本要收集，脏数据、权限不足、工具失败、恶意输入更要进入反例集。

· 失败要能归因：是模型理解错了，还是上下文缺了？是工具不可用，还是策略允许了错误动作？是交互没有让用户及时纠偏，还是任务本身就该升级给人？

评测的价值不是制造一个漂亮数字，而是让团队知道下一刀该切在哪里。改了提示词、换了模型、调整了工具描述、重排了工作流之后，关键任务是变稳了，还是在另一个地方退化了？没有这套判断系统，AI 产品的迭代很容易变成"感觉更好了"。

好的交互，是让用户敢放手，也能接住

AI 产品的交互难点，不在于页面多漂亮，而在于控制权怎么分配。

用户不想学习提示词工程。他们希望用自然语言表达目标，然后让系统补全背景、识别歧义、确认约束。与此同时，他们也不希望 AI 在黑盒里一路狂奔，尤其是涉及发消息、改文件、提交审批、扣费、删除数据这类动作时。

所以交互要处理几件具体的事：

· 入口要轻，帮助用户把目标说清楚，而不是要求用户一次性写完完整需求。

· 过程要可理解，只展示计划、资料、工具调用和关键决策，不把推理碎片一股脑倒给用户。

· 控制权要能拿回来，支持确认、编辑、撤销、重试、切换方案和人工接管。

· 失败要可恢复，用户需要知道是没数据、没权限、服务失败，还是 Agent 自己判断不了。

真正好的 AI 交互，不是让用户觉得系统无所不能，而是让用户知道：哪些地方可以委托，哪些地方仍然由自己拍板。

策略决定 Agent 在异常现场怎么做

很多团队第一次做 Agent，会把策略写进一段更长的 system prompt。这样能快速跑出 demo，却很难扛住真实场景。

策略不是提示词装饰层。它是产品判断的可执行形式：什么信息必须先拿到？什么时候应该追问？什么时候调用工具？工具失败后是重试、换路，还是交给人？任务完成到什么程度才算可以停止？哪些动作必须明确授权？

下面这张表更接近真实现场：

任务现场	只靠模型时容易发生什么	策略应该补上的判断
用户只说"帮我发给客户"	直接生成并发送，收件人、语气、附件都可能错	识别客户、目标、附件、发送时机；缺信息先追问，发送前确认
工具返回空结果或报错	编造答案、反复调用，或者直接中断	区分没有数据、权限不足、服务失败；给出重试、替代路径或人工接管
动作不可逆	为了完成任务越权执行	解释影响，展示变更范围，要求授权，留下审计记录
任务链路很长	上下文膨胀，目标漂移，最后给出看似完整的结果	分阶段保存状态，设置检查点、停止条件和质量门槛

策略的竞争力往往不体现在一次回答多惊艳，而体现在连续十次、遇到异常、触及风险时，产品仍然知道下一步该怎么走。

Harness：把策略变成 Agent 的运行循环

如果说策略回答"Agent 应该怎么判断"，Harness 解决的是"这些判断如何在系统里稳定发生"。

可以用一个简化公式理解它：

Harness = LLM + Tool Use + Environment + Memory

它不是单一框架，也不是某个新名词，而是一整套运行与控制机制。它让大模型不只是单次生成文本，而是在真实任务里持续计划、行动、观察、校正。

一个可用的 Harness 至少要管住这些环节：

· 上下文管理：当前任务需要哪些事实、历史、约束和指令？哪些信息会变成噪声？

· 记忆管理：哪些信息只在本轮有效，哪些值得跨任务保存？错误记忆如何被纠正？

· 策略注入：角色、规则、质量标准、任务模板和动态上下文应该以什么优先级生效？

· 工具编排：给 Agent 哪些工具，如何描述工具，何时允许调用，工具失败后怎样恢复？

· 环境与安全：Agent 能访问哪些数据，能执行哪些动作，哪些动作必须确认？

· 模型路由：不同任务是否需要不同模型、不同深度，什么时候自检、复核、重试或交给人？

更直观地看，Harness 是一条循环：

产品在每个节点都有事可做。目标是否被拆成可检查的子任务？工具返回是否足够结构化？观察结果会不会写回状态？什么信号触发重试，什么信号触发人工介入？这些问题的答案，决定了 Agent 是"生成一段内容"，还是"完成一段工作"。

AI 产品经理要懂技术，但不是去背技术名词

很多人一说要懂 AI，就立刻去补 Transformer、RAG、fine-tuning、SFT。了解这些当然有价值，它们能帮助判断能力边界、成本结构和方案取舍。但对产品工作来说，更重要的问题是：这些知识能不能进入一次真实产品决策？

如果看完一堆模型原理，仍然不知道 Agent 为什么失败，不知道该补上下文、改工具、调策略，还是重做交互，那这次学习就没有转化成产品能力。

更合适的顺序通常是：

先理解业务：用户真正要完成什么任务，原流程哪里摩擦最大，什么结果才算有价值。
再设计产品：用户如何表达目标，什么时候追问，什么时候展示过程，什么时候把控制权交还给人。
最后建立策略与评测：Agent 如何行动、何时停止、失败后如何恢复，团队怎样判断它真的变好了。

AI 产品需要懂技术，不是为了变成算法工程师，而是为了把用户价值翻译成模型、工具、上下文、策略和评测都能执行的系统设计。

新概念会变，但默认能力不会消失

这两年围绕 AI 产品冒出了很多说法：提示词工程不重要了，上下文工程过时了，Harness Engineering 才是未来，或者又出现 Loop Engineering、Graph Engineering。新概念值得看，但没必要把它们理解成"旧能力已经没用了"。

很多技术不会死，只是对人的要求变低了。

模型、框架和工具会把复杂细节封装起来，入门门槛会下降。但这通常意味着某项能力变成默认前提，而不是从产品里消失。提示词还在，只是被封进模板、策略和工具描述；上下文还在，只是变成检索、记忆和状态管理；工作流还在，只是从线性流程走向循环、分支和图结构。

对 AI 产品来说，真正危险的不是暂时没追上一个新名词，而是误以为一段时间不学 AI，就不用学了。等这些能力成为行业默认配置，再回头补共同语言和判断力，成本会更高。

学 Harness，最好从真实项目拆起

理论可以建地图，实践才会让人知道路面坑在哪里。

我更建议从一个足够小、能跑起来、能看懂关键流程的开源项目开始。不要一上来就试图读完整个仓库，而是带着产品问题去拆：

· 用户目标在哪里进入系统？

· Agent 的状态保存在哪里？

· 上下文如何被压缩、检索和更新？

· 工具如何定义，失败如何处理？

· 哪些动作需要确认，哪些动作可以自动执行？

· 评测如何建立，错误如何复盘？

Pi Agent Harness 适合观察 coding agent 如何组织模型调用、工具与状态。它默认以启动进程的权限运行，安全隔离需要另外用容器或沙箱补足，这正好能帮助理解"环境与边界"不是工程细枝末节，而是产品策略的一部分。

OpenWorker 更适合观察面向真实工作任务的桌面 Agent 如何组合模型、连接器、审批、记忆与自动化。它采用 local-first 设计，但数据边界仍取决于所选模型与已连接集成。先跑通一个最小任务，再反推每个模块承担了什么策略责任，会比只看架构图有效得多。

每次练习最后都可以回到同一个问题：我是否更能区分"模型能做什么""产品该做什么""人必须保留什么"？

结语

AI 产品的机会不只是接入更强模型，而是围绕真实用户目标，搭出一个能持续变好的系统。

评测让团队知道什么算好，交互让用户敢于委托，策略让 Agent 在不确定环境里做出选择，Harness 则把这些判断落到每一次计划、行动、观察和校正里。

未来更有竞争力的 AI 产品，不会只属于最会解释模型的人，而会属于那些能把产品判断、技术理解和真实任务揉进同一套运行机制的人。