Agent落地深水区：WorkBuddy如何用Harness工程将模型转化为可靠产品
在AI Agent从技术原型走向规模化产品落地的过程中，一个普遍的认知误区是：只要模型足够强大，或者提示词（Prompt）写得足够详尽，Agent就能稳定完成任务。然而，一线实践表明，模型能力仅仅是起点。真正决定Agent在生产环境中可靠性的，是它如何被引导、上下文如何被组织、工具与权限如何接入、结果如何被验证，以及Harness（驾驭/控制环境）如何将不确定的模型输出转化为可控的执行过程。
一、 重新定义模型：从“全知全能”到“无状态函数”
要构建可靠的Agent产品，首先需要对大语言模型（LLM）进行去魅，将其抽象为一个无状态的函数。从产品运行机制来看，模型的核心价值在于语言理解、推理和生成，但它并不具备自动保留状态、实时联网或执行外部动作的能力。
模型的训练过程通常分为预训练、后训练和偏好优化三个阶段，最终得到一个具备基础知识和指令遵循能力的基座。但在实际调用中，模型的行为由以下公式决定：
输出 = 模型(系统提示词 + 工具定义 + 会话历史 + 动态上下文 + 用户指令)
这一抽象揭示了两个关键约束：
- 无状态性：模型本身不记忆任何内容。对话历史、工作进度、用户偏好等状态必须由产品在模型外部维护，并在每次请求时显式注入。WorkBuddy等产品的连续性体验，正是通过产品侧的状态管理实现的。
- 知识截止性：模型无法感知训练日期之后的实时信息。对于实时数据或外部系统操作，必须通过工具调用（Function Call）将结果回传至上下文，模型才能基于最新信息进行推理。
因此，Agent的工程化核心，不在于提升模型本身的参数规模，而在于构建一个能够弥补模型缺陷的外部执行环境。
二、 能力组件的层级架构：MCP、Skill与Plugin
Agent需要与外部世界交互，这涉及工具调用、上下文协议、任务流程和分发机制四个层面的标准化。
1. 工具调用（Function Call）：动作的执行协议
工具调用是模型与外部系统交互的结构化协议。模型负责生成调用请求，而Agent负责执行。关键在于，持有API Key、发起请求和修改数据的主体是Agent，而非模型。因此，权限校验、参数验证和审计日志必须位于模型外部的执行层，这是防止高风险操作失控的第一道防线。
2. 模型上下文协议（MCP）：标准化的外部接入
MCP（Model Context Protocol）解决了外部系统接入的标准化问题。它定义了三种原语：
- Resources（资源）：由Agent驱动读取的只读数据，如文件、数据库记录。
- Tools（工具）：由模型驱动执行的动作，如查询、修改。
- Prompts（提示模板）：由用户触发的预定义指令组合。
MCP的核心价值在于统一了连接协议，使得Agent无需为每个外部系统编写专用适配器。同时，MCP Apps的扩展允许工具返回可直接渲染的UI，实现了面向模型的数据与面向用户的界面的分离，优化了上下文占用。
3. Skill（技能）：任务流程的沉淀
单一工具无法完成复杂任务。Skill是将经过验证的工作方法保存下来的机制，包含步骤、约束、脚本和验收标准。例如，“创建PR”不仅涉及API调用，还包括读取仓库规范、运行测试、生成描述等流程。Skill解决了“这类任务应该怎么做”的问题，与解决“外部系统怎么接入”的MCP形成互补。
4. Plugin（插件）：能力的打包与分发
Plugin是产品层的能力组合单位，将MCP连接、Skill流程、Rules规则和Hooks钩子打包，支持按团队或项目作用域安装。它解决了能力如何安装和分发的问题，是Agent生态扩展的基础。
三、 Context Engineering：决定模型“看到”什么
Context Engineering（上下文工程）的核心目标是：在模型决策前，设计哪些信息进入上下文、以何种形式进入、放在什么位置，以提高正确决策的概率。其包含五类动作：写入、选择、检索、压缩和隔离。
1. 渐进式加载与Prompt Cache
随着工具数量的增加，全量加载工具定义会导致上下文膨胀和语义干扰。WorkBuddy采用渐进式加载策略：默认仅暴露工具名称和简要描述，根据意图识别结果按需加载详细Schema。同时，为了优化成本，遵循Prompt Cache的前缀复用原则：将稳定的System Prompt和基础工具定义置于前部，动态内容（如当前文件、任务进度）追加至后部，确保缓存命中率。
2. 记忆系统（Memory）的分层与准入
记忆系统解决的是“让正确的过去在正确的时候重现”。WorkBuddy将长期记忆分为五类：稳定事实、用户知识背景、行为信号、表达偏好和会话延续信息。关键在于区分陈述性记忆（存什么）与作用域（在哪里生效）。
值得注意的是，WorkBuddy未将程序性记忆（Procedural Memory，即“做事的方法”）纳入长期记忆，而是将其沉淀为Skill。这是因为程序性记忆一旦注入上下文，会直接干扰模型的推理路径，导致局部经验被误升为通用策略，降低系统的泛化能力和可控性。
四、 Harness Engineering：引导、约束与整合
Harness Engineering（驾驭工程）解决的是Agent执行过程中的方向、安全和编排问题。它由构建者和使用者共同维护，包含驾驭（Steer）、约束（Constrain）和整合（Integrate）三类能力。
1. 五层Harness架构
WorkBuddy构建了五层Harness体系：
- 运行环境层：提供文件系统、Shell、沙箱、权限边界等基础执行环境。
- 引导层（Feedforward）：在执行前提供项目上下文、环境信息、规则文件和Skill，提高首次执行的正确率。
- 反馈层（Feedback）：通过Lint、类型检查、单元测试等确定性信号，以及架构审查等推断型信号，验证执行结果并将错误反馈给Agent，实现自我纠正。
- 编排层：管理多Agent协作、并行工具调用和意图路由，优化资源分配。
- 迭代层：根据模型能力提升和新出现的问题，持续调整Harness配置，如精简上下文、增加约束或适配新工具。
2. 前馈与反馈的平衡
有效的Harness必须同时具备前馈和反馈。前馈通过规则和上下文引导Agent方向，反馈通过验证和纠错机制修正偏差。WorkBuddy的原则是：能用确定性程序（计算型）解决的问题，优先交给程序；需要语义判断的问题，再交给审查Agent（推断型）。这种分层反馈机制确保了系统的效率与准确性。
五、 Loop Engineering：跨时间的任务循环
Loop Engineering关注任务如何被触发、流转、验证和停止。它依赖Harness提供的约束和验证机制，将单次执行扩展为长期稳定的任务循环。
一个完整的Loop包含触发器、独立执行环境、工具、验证信号和停止条件。例如，每日依赖安全更新检查Loop：定时触发后，Agent在独立Worktree中读取规则、查询更新、执行测试、生成PR，并将结果写入记忆。Loop不会自动产生正确目标或可信的验收标准，因此必须结合人类的责任边界和审批机制。
六、 未解决的挑战与未来展望
尽管Harness工程取得了显著进展，但仍面临几个核心挑战：
- 业务正确性验证缺口：目前的Harness主要关注代码质量和架构规范，缺乏对功能和业务逻辑的规模化验证方法。需求的不完整性和实现与测试共享误解的风险，使得核心业务逻辑的自动化仍需人类深度参与。
- 老系统的Harnessability：历史遗留系统结构复杂、缺乏可观测性，构建Harness的难度极大。建议优先处理模块边界和关键链路测试，逐步扩展Harness覆盖范围。
- 技术栈的标准化趋势：AI Agent的普及可能推动技术栈的标准化。团队可能优先选择结构清晰、易于AI理解和验证的技术方案，以减少Harness构建成本。
结语
Agent的产品化是一个系统工程，模型能力决定了上限，而上下文工程和Harness工程决定了这一上限能否稳定落地。通过分层管理上下文、精细化控制记忆、构建多层反馈的Harness体系，以及设计可持续的Loop循环，WorkBuddy等实践展示了将不确定的模型输出转化为可靠产品能力的路径。未来，随着Harness工程的成熟，AI Agent将从辅助工具演变为具备高度自治能力的数字员工，但人类在目标设定、标准定义和责任承担上的核心角色不可替代。
