读《WorkBuddy如何把Agent做成可用产品》：拿着它对照了一遍我们自己的项目
今天看到腾讯技术工程发的一篇文章：从模型到Harness：WorkBuddy如何把Agent做成可用产品，作者 Anne 是 WorkBuddy 团队的策略产品经理，负责研发与办公场景 Agent 的上下文策略。
这篇我觉得写得特别好。倒不是里面有什么新概念——Function Call、MCP、Skill、Plugin、Context Engineering、Harness，这些词单独拿出来都见过。难得的是它把这些词放进了同一张图里，而且每个概念都回答了两个问题：它解决什么问题，它在产品里到底长什么样。
上周我刚写过一篇《重新理解我们的AI视频项目：我们正在做的其实是一套Harness》，当时的判断主要来自 Lilian Weng 的文章和自己的项目体感。WorkBuddy 这篇相当于把那个视角继续落到了产品细节上，细到可以当检查表用。
所以我读完做的第一件事，就是拿着它把我们在做的两个仓库对照了一遍：narrative-code（基于 OpenCode 的客户端运行时）和 narrative-codex（跨仓规格源）。这篇读后感主要记录这次对照。
文章讲了什么
先把骨架记下来，后面对照要用。
文章的起点是一个抽象：模型是无状态函数，输出 = 模型(系统提示词 + 工具 + 会话历史 + 其他上下文 + 用户指令)。它不存状态，知识有截止日期，所以记忆、工具执行、权限这些全部要由产品在模型外部补齐。往上是四个用户能感知到的概念：Function Call 是模型请求动作的协议，MCP 解决外部系统怎么标准化接入，Skill 解决一类任务应该怎么做，Plugin 解决一组能力怎么打包分发。
再往上是三层工程。Context Engineering 回答”模型这一刻该看到什么”，拆成写入、选择、检索、压缩、隔离五个动作，目标是相关、准确、及时，不是堆 token。Memory 回答”哪些过去可以在未来重现”，其中有个我很认同的取舍：WorkBuddy 只把陈述性记忆（用户是谁、了解什么、发生过什么）放进长期记忆，程序性记忆（做事方法）交给 Skill，因为 Skill 可版本化、可评审、可回滚。Harness Engineering 回答”怎么让执行稳定可控”，分成运行环境、引导（Feedforward）、反馈（Feedback）、编排、迭代五层——前馈提高首次正确率，反馈让 Agent 在人工审查之前先自我纠正。最后 Loop Engineering 把这套东西放进时间维度：触发器、执行环境、Durable Artifacts、Sensors/Evals、Stop Conditions/Budget。
对照下来，我们其实已经在做的一些事
有些设计我们当时做的时候并没有用这些名字，对照完才发现是同构的。
比如 Prompt Cache。文章说 WorkBuddy 组织上下文时遵守”稳定内容放前面、历史只追加、动态内容放后面”，目的是命中缓存前缀。narrative-code 的 CONTEXT.md 里定义的 Context Epoch 做的就是这件事：一个 Epoch 内 Baseline System Context 不可变，运行中变化的 Context Source 只能以 Mid-Conversation System Message 的形式按时间序追加，直到压缩或 Session 移动才重开基线。我们还多走了一步：Baseline 的完整拼接文本被持久化，进程重启后逐字复用。
比如渐进式加载。文章讲工具结果过长要截断或写文件，工具定义过多要先暴露名称简介、按需加载完整 Schema，Skill 也是先看描述、确认适用再读完整 SKILL.md。narrative-code 的 Managed Tool Output File 是同一件事：超长工具结果在 Session 历史里只留有界预览，完整文本移到受管目录，模型按路径继续读。Skill 指引也作为一个 Context Source 只列出名称和描述，正文要通过权限检查的 skill 工具按需加载。
再比如”计算型控制优先”。文章的原则是能用 linter、类型检查、单测这类确定性信号解决的问题，不要交给模型判断；语义判断才留给审查 Agent，而且要放在更靠后的检查阶段。narrative-codex 的设计文档里有一条几乎一样的话：P0 不必把评测包装成会聊天的 Evaluation Agent，确定性规则优先，确实需要模型时再调模型，并保存输入、规则版本和结果。Approval Gate 也是类似的：我们的 Tool Catalog 里每个工具都标了副作用和确认策略，高成本重生图要确认，对外发布 P0 必须人工确认，requires_confirmation 直接写进 Skill 合同。
还有”程序性知识放 Skill 不放 Memory”这一条。narrative-codex 整个仓库其实就是这个原则的实践：规格有稳定 ID、有测试 Oracle、有固定 Commit 引用，被取代的文档标注状态和替代链接，而不是并行搞一个”最终版”。
差距在哪里
对照更值钱的部分是缺口。按文章的框架看，我们至少有五处明显不足。
第一，Memory 这一层基本是空的。 文章里的 Memory 是一个有准入判断的系统：哪些历史信息有资格进入后续上下文、在什么作用域生效（当前轮 / Thread / Workspace / 用户 / 团队）、什么时候注入、怎么撤销。我们目前只有两类东西：规格文档（人工维护的”团队记忆”）和 Session 历史。没有用户级记忆，没有行为信号，也没有”任务收尾时从结果和用户纠正里提取候选记忆”这个环节。创作者改了三次都选同一种叙事角度，系统不会记住。而且文章的提醒对叙事场景特别相关：发生过的事不该无差别影响未来——上一个视频的题材偏好如果被带进下一个视频，就是内容同质化。
第二，反馈层还不够深。 文章里几个具体机制，我们都有缺口。工具错误要返回可纠正信息——文件未找到时提示搜索路径、编辑失败提示重读——而不是只回 error 或堆栈；我们的 Narrative REST API 错误格式还没有按”模型可读、可自纠”来设计。编辑前要做时间戳校验，防止 Agent 用旧状态覆盖用户刚改过的内容；这一点对我们的白板编辑场景很直接，用户在 Web 编辑器里改了布局，Agent 不该覆盖回去。另外文章提到周期性传感器和熵管理——死代码扫描、规格与代码一致性检查、过期依赖——narrative-codex 现在靠人工重基线发现漂移，没有自动化扫描。
第三，编排层有 Workflow，但缺意图路由和隔离。 我们 P0 是 Workflow 驱动的，状态机很完整（Intake → Script → Planning → Audio → Imagery → Render → Metadata → Evaluation → Review → Publish），但入口处的意图识别是薄弱的：用户一句话到底是”新建视频”、“改上一版”还是”只改字幕”，目前靠 Agent 自由判断，没有显式路由。文章还多次提到用 Sub-agent 隔离上下文，把旁支任务的结果带回主线、避免污染主上下文。这一点我们的工程 Harness 里已经在用（给 Codex、GLM、Kimi 分派独立任务），但产品 Harness 里还没有这层设计。
第四，Loop Engineering 只拼齐了一半。 文章列的组件里，我们的服务端链路有触发器（资讯 Push/Callback）、有持久任务和 Worker、Workflow 有状态机。但 Stop Conditions 和 Budget 还没有变成显式合同：一个无人值守任务最多重试几次、烧多少成本、什么情况必须停下来等人，这些还散在各处，没有统一成 Loop 的停止条件。Sensors/Evals 也只覆盖了生产质量，没有覆盖 Loop 本身的健康。
第五，Harness 自身的迭代缺一个证据环。 文章的迭代层强调”一次失败可能是偶发，同类失败多次出现再调整”，新增机制还要评估副作用。我们现在改规格的触发基本是”人工发现问题 → 人工改 Spec”，失败记录没有结构化沉淀，说不清”哪个 Skill 的哪条约束是从哪几次失败里长出来的”。这正是我上一篇说的”还不能叫自我改进系统”的那块缺口，这篇文章把它讲得更具体了：先要有失败记录的结构化，才谈得上迭代证据。
一个文章也没解决的问题，恰好是我们最难的
文章最后坦承了一个缺口：功能和业务正确性的验证。需求很难完整说明，实现和测试可能共享同一个误解，部分业务正确性缺少可计算的判定标准。
对代码类 Agent 这已经是难题，对叙事创作更严重。一个脚本”事实正确、时长达标、合规通过”，和它是一个”好内容”，中间隔着整个编辑部。我们 Golden Case 的做法——冻结一条嫦娥六号的完整案例，用 Gate A/B Oracle 验收——这个做法就是用少数人工精标的样本，去逼近那个没法写成规则的标准。
这条路目前看是对的。但文章的框架提醒我们：Golden Case 是评测资产，不是评测体系。样本数量、覆盖面、版本管理、生产质量信号的回流，都是后面要补的。
接下来要做的几件事
对照完以后，我把要补的东西按优先级排了一下：
- 给 Loop 补停止条件和预算合同。这是无人值守链路上线前的硬门槛，比 Memory 更急。
- 工具错误格式按”可自纠”重构。成本低、收益直接，从 Narrative API 的错误回执开始。
- 白板类编辑加冲突校验，防止 Agent 覆盖用户在编辑器里的改动。
- 失败记录结构化：每次 Workflow 失败记录失败环节、错误类型、是否可重试，作为 Harness 迭代的证据层。
- Memory 先做准入判断再做存储。哪怕第一版只在任务收尾时提取候选记忆并让人确认，也比直接自动写入强。
- 意图识别显式化。至少在入口把”新建 / 改写 / 局部编辑 / 查询状态”四类意图分开路由。
最后说一个读完以后更确信的判断。文章引了一句话：“Our most difficult challenges now center on designing environments, feedback loops, and control systems.” 模型会继续变强，但模型变强不会自动消化掉这些东西——上下文组织、反馈回路、权限边界、停止条件，不会因为换了个更强的模型就消失，只会因为模型变强而更值得认真做。
这也是我现在判断我们自己项目进展的标准：不只看演示能不能跑通，而是看这套 Harness 的每一层——运行环境、引导、反馈、编排、迭代——是不是都有真实的东西在填。