超越模型能力：WorkBuddy如何构建Agent稳定执行的工程闭环
我们常有一种直觉，认为提升AI智能体（Agent）表现的最优解是更换更强的基座模型，或者撰写更详尽复杂的提示词（Prompt）。然而，当这一假设进入一线生产环境时，往往会被现实打破。模型能力仅仅是智能体可用的起点，真正决定其能否稳定完成任务的，是上下文如何被精密组织、工具和权限如何接入、结果如何被严格验证，以及Harness（控制框架）如何将模型那些充满不确定性的输出，转化为稳定且可控的执行过程。
一、重新定义模型：无状态函数的工程视角
在产品工程视角下，理解大语言模型（LLM）需要剥离Transformer底层的复杂数学原理，将其抽象为一个简单的函数：Output = Model(System Prompt + Tools + History + Context + Instruction)。这一抽象揭示了两个至关重要的约束，这也是所有上层工程机制存在的根本理由。
首先，模型本质上是无状态的。它不会自动记忆上一次对话的内容。虽然模型本身不存储数据，但产品层必须维护状态。对话历史、记忆库（Memory）以及工作进度，都需要由产品侧在模型外部保存，并在每次调用时显式注入上下文。WorkBuddy的对话连续性正是通过这种“外部状态+内部注入”的方式实现的，模型本身并不承担存储职责。
其次，模型的知识具有截止时间。训练截止日期之后的实时信息或内部私有数据，模型默认无法掌握。因此，涉及实时赛况或内部数据库的操作，必须通过外部工具获取结果后，再作为上下文的一部分喂给模型。这意味着，模型提供的是推理与生成能力，而工具接入、环境感知和执行动作，必须由模型外部的工程机制来完成。
二、能力扩展：从工具调用到标准化协议
为了让具备语言能力的模型能够作用于物理或数字世界，需要构建一套标准化的能力接入体系。WorkBuddy通过梳理工具调用、MCP协议、Skill和Plugin四个层次，解决了能力组织的问题。
**工具调用（Function Call）**是模型与外部系统交互的基础协议。模型负责生成结构化的调用请求，而Agent负责执行校验、权限检查和实际API调用。关键在于，持有API Key和执行操作的是Agent而非模型，因此权限边界和审计日志必须由模型外部的系统严格控制。
随着接入系统增多，**模型上下文协议（MCP）**应运而生。MCP通过统一接口连接AI应用与外部数据源，提供了Resources（只读资源）、Tools（可执行动作）和Prompts（提示模板）三种原语。它解决了“外部系统如何标准化接入Agent”的问题，避免了为每个系统单独开发适配代码的高昂维护成本。值得注意的是，MCP不仅是工具协议，更是上下文传递的协议，允许将部分数据直接渲染给用户，而非全部塞入模型上下文，从而优化Token成本。
**Skill（技能）**则进一步沉淀了“一类任务的做法”。与Tool仅负责单一动作不同，Skill包含了一组经过验证的工作流、判断标准和脚本。例如，“创建PR”不仅涉及API调用，还包括读取规范、运行测试、生成描述等步骤。Skill让Agent知道在特定场景下“应该怎么做”，而不仅仅是“能做什么”。
**Plugin（插件）**则是能力的打包与分发单位。它将MCP连接、Skill流程、规则文件（Rules）和Hooks组合成一个可安装、可分发的组件包。这使得复杂的工作流（如团队研发流程）能够像软件模块一样，按团队或项目作用域灵活部署。
三、Context Engineering：决定模型看到什么
在明确能力边界后，核心挑战转向如何管理上下文。Context Engineering旨在设计进入模型上下文的信息、形式与时机，以提高决策准确率。WorkBuddy将其归纳为写入、选择、检索、压缩和隔离五类动作。
一个常见的误区是试图将所有可用信息全部放入上下文。实际上，无关信息不仅增加成本，更会稀释模型对重点的判断。**Prompt Cache（提示词缓存）**机制要求保持System Prompt和基础工具定义的稳定性，采用“前缀稳定+动态追加”的策略，以最大化缓存命中率，降低推理成本。
针对长任务和大型工具集，WorkBuddy采用渐进式加载策略。默认只暴露工具名称和简介，根据意图识别结果按需加载详细Schema；工具结果过长时分页或写入文件，并明确告知截断位置。这种“按需展开”的机制，确保了上下文始终只包含当前任务最相关的信息，避免了信息过载导致的幻觉或偏离。
四、Memory与Harness：让智能体具备“记忆”与“约束”
**记忆系统（Memory）**旨在解决重复交代背景的问题，但并非所有历史都适合被记住。WorkBuddy将记忆分为稳定事实、知识背景、行为信号、表达偏好和会话延续五类，并严格区分陈述性记忆与程序性记忆。程序性记忆（即“做事的方法”）被排除在长期记忆之外，以避免局部经验被误升为通用策略，干扰模型推理。相比之下，经过人工提炼、可版本化和回滚的工作方法，应保存为Skill。
如果说上下文工程解决的是“知道多少”的问题，那么**Harness Engineering（驾驭工程）**解决的是“执行是否可控”的问题。Harness一词原指马具，包含驾驭（Steer）、约束（Constrain）和整合（Integrate）三层含义。
- 驾驭：通过System Prompt、规则文件和Task拆解，引导执行方向。
- 约束：通过权限边界、沙箱环境、审批网关（Approval Gate）和Allowlist/Denylist，防止危险操作。
- 整合：将工具、状态、协作机制（如Sub-agents）协同编排，形成稳定系统。
WorkBuddy构建了五层Harness架构：运行环境层（提供基础执行空间）、引导层（前馈信息）、反馈层（后验验证）、编排层（多能力协同）和迭代层（持续优化）。其中，反馈层尤为关键，它通过Lint、类型检查、单元测试等计算型信号快速纠正错误，并结合架构审查等推断型信号处理语义层面的复杂问题。这种“计算优先、推断补充”的策略，在保证效率的同时提升了系统的鲁棒性。
五、Loop Engineering：跨越时间的持续执行
单次任务的优化最终需要服务于长期工作流，这引入了Loop Engineering的概念。Loop Engineering关注任务如何被触发、流转、验证并再次运行。一个完整的Loop包含触发器、独立执行环境、工具链、记忆载体、传感器和停止条件。
以“每日依赖安全检查”为例，Loop会在特定时间触发，创建隔离工作树，读取相关Skill，查询漏洞，执行更新与测试，最后生成PR或报告。关键在于，Loop并非万能，它依赖于Harness提供的验证机制。如果目标错误或缺乏可信的验收标准，Loop只会加速执行错误的路径。因此，Loop设计必须包含明确的风险评估和人工审批边界，特别是涉及核心业务逻辑时。
六、未竟之处与未来展望
尽管Context、Memory和Harness工程显著提升了Agent的可靠性，但仍有边界：
- 业务正确性验证缺口：目前的验证多集中在代码质量和架构规范，缺乏对业务意图的规模化验证。实现与测试若由同一Agent生成，可能共享同样的理解偏差，导致“错误的实现通过了测试”。
- 老系统的Harnessability难题：结构混乱、缺乏测试和历史违例过多的老系统，构建Harness的成本极高。建议先治理核心链路，再逐步扩展。
- 标准化趋势：未来技术栈的选择可能不仅基于性能，还将考虑其“AI友好度”。结构清晰、约定统一的系统更易于Agent理解和验证，这将推动技术方案的标准化。
结语
模型决定了智能体的能力上限，而上下文工程与Harness工程决定了这一上限能否在现实中稳定落地。WorkBuddy的实践表明，通过精密的上下文管理、分层约束机制和持续反馈闭环，可以将不确定的AI输出转化为可靠的生产力工具。然而，AI仍无法替代人类的最终判断，人在设定目标、定义标准和承担责任方面依然处于核心地位。
随着技术的演进，工程师的职责正从单纯的代码编写，转向设计更完善的执行环境、反馈回路和控制系统。这不仅是工具的升级，更是软件工程范式的一次深刻变革。
