谈起 AI Agent 的落地，不少人的第一反应是 “换个更强的基座模型”“把提示词写得更详尽”。但真正深入生产场景做过落地就会发现，模型能力只是整个产品的起点。Agent 能不能稳定完成任务、能不能被用户放心使用，更多取决于它如何被引导、上下文如何组织、工具权限如何管控、结果如何被验证 —— 本质上，是如何用一套工程体系，把模型天然不确定的输出，转化为稳定可控的产品能力。

结合这段时间阿宇对 Agent 产品的实践与思考，我想沿着 “模型 — 上下文 — 执行管控 — 长期循环” 这条核心链路，聊聊对于把 Agent 从 “能跑通 Demo” 推进到 “可用产品” 的思考与看法。

一、先把模型看明白：它只是一个无状态的推理函数

做 Agent 产品，首先要放下对模型的 “全能幻想”。从产品视角看，我们不需要深究 Transformer 的底层原理，只需要抓住一个核心抽象： 模型本质是一个根据输入生成后续内容的无状态函数。

1. 模型能力的三个来源

模型的推理与理解能力，来自三个阶段的持续训练：

• 预训练阶段：在海量文本中反复学习 “根据前文预测下一个 token”，习得语言能力、世界知识和基础推理能力，这个阶段的模型仅具备内容续写能力。
• 后训练阶段：通过问答、工具调用、安全边界等定向数据，把基座模型训练成能听懂指令的助手，让它可以直接回答事实类问题。
• 偏好优化与强化学习阶段：通过人类反馈对候选答案打分，让模型更倾向于选择有用、准确的回答；对多步骤任务，则通过结果质量、执行效率、规范度的综合打分，让模型收敛到更优的执行路径。

2. 两个决定上层工程的核心约束

这个函数式的抽象，自带两个底层约束，也正是所有 Agent 工程体系存在的根本原因： 第一，模型是无状态的。它不会自动记住上一次调用的内容，所有对话历史、任务进度、用户偏好，都需要产品在模型外部保存，在需要的时候注入到本次输入中。所谓的 “对话连续性”“记忆能力”，本质都是产品侧维护状态再注入的结果，与模型本身无关。 第二，模型知识有截止日期。训练完成后发生的实时信息、企业内部的私有数据，模型天然不掌握，必须通过工具查询后再放进上下文，模型才能基于这些信息作答。

换句话说，模型只负责提供语言理解、推理和生成能力；读取文件、查询数据、执行命令这些外部动作，都不是模型自带的能力，必须由产品层接入工具和执行环境。

二、Agent 能力层：从单次动作到可分发的能力包

有了基础模型，Agent 要落地就需要接入外部能力。很多人对工具调用、MCP、Skill 这些概念容易混淆，其实它们对应了不同层级的问题，各司其职。

1. 工具调用：模型与外部系统的基础协议

工具调用（也常叫 Function Call）是模型请求执行动作的结构化协议 —— 模型生成调用请求，Agent 系统负责实际执行。 完整流程清晰明确：产品把工具的名称、用途、参数规则告知模型；模型根据用户目标生成结构化的调用请求；Agent 系统校验参数、检查权限后执行对应的 API 或脚本；最后把执行结果放回上下文，由模型判断是直接回答还是继续调用其他工具。 这里有个极易被忽略的关键点：真正持有权限、执行操作的是 Agent 系统，不是模型。所以参数校验、权限审批、审计日志，必须全部放在模型外部的执行层，这是管控高风险操作的核心前提。

2. MCP：外部系统的标准化接入方案

当 Agent 需要对接的外部系统越来越多 —— 代码仓库、文档系统、网盘、内部平台 —— 如果每个系统都单独做适配，很快就会陷入维护噩梦。模型上下文协议（MCP）解决的，就是外部能力接入的标准化问题。 很多人以为 MCP 只是 “统一工具接入”，其实它提供了三类原语，覆盖了信息、动作、模板三个维度：

• 资源（Resources）：有唯一标识的只读内容，比如文件、数据记录，由 Agent 按需读取后直接注入上下文，不需要走工具调用流程。
• 工具（Tools）：模型可主动调用的动作，也就是常说的工具调用，由模型驱动。
• 提示模板（Prompts）：预先组织好的可复用消息组，由用户主动触发，比如斜杠命令，内部可以关联对应资源。 MCP 的核心价值，是用一套统一协议对接所有外部系统，后端不管是 REST 接口、数据库还是 SDK，Agent 都不需要感知差异。而好的 MCP 服务，一定是按用户意图组织工具，而非照搬底层 API—— 比如 “创建 Issue” 底层可能涉及四五个接口，但对模型只暴露一个工具，把相关参数整合进去。

3. Skill：沉淀一类任务的标准流程

真实工作里，很少有任务只调用一次工具就能完成。比如提交一个 PR，需要先读仓库规范、检查本地修改、运行测试、生成变更说明，最后才创建 PR。 Skill 解决的就是 “一类任务该怎么做” 的问题，它把经过验证的工作方法、步骤、判断标准、失败处理逻辑沉淀下来。模型匹配到对应任务时，先读取 Skill，再按流程执行，避免每次都从零开始摸索。 一句话区分：MCP 解决 “外部能力怎么接进来”，Skill 解决 “这类任务按什么流程做”。两者可以组合使用，比如一个 “发周报” 的 Skill，可能同时调用文档 MCP、知识库 MCP 和本地脚本。

4. Plugin：能力组合的打包与分发

真实的团队场景里，一套完整的工作能力往往不只是一个工具或一个流程，而是连接、流程、规则、模板的组合。 Plugin 解决的就是 “一组能力怎么安装和分发” 的问题，它把 MCP 连接、Skill 流程、团队规则、钩子脚本、模板资产打包成一个可安装的单元，支持按团队、项目、个人维度安装启用。比如一个研发流程 Plugin，会同时包含代码仓库的 MCP 连接、提 PR / 查构建的 Skill、分支与提交规范、提交前检查的钩子，还有 PR 模板等资产。

5. 能力接入的形态选择

不是所有能力都要用同一种形态接入，判断的核心是能力边界、更新频率、权限风险、上下文成本和复用价值：

• 稳定的底层操作（比如读文件、执行命令），优先做成内置工具，延迟低，权限和交互能深度集成。
• 外部系统接入，优先用 MCP 标准化复用，服务端集中维护。
• 团队高频的稳定工作流程，沉淀为 Skill，固化步骤与验收标准。
• 需要同时包含连接、流程、规则的完整能力，打包成 Plugin 做分发。

三、Context Engineering：让模型这一刻只看该看的信息

很多人做 Agent 有个误区：觉得上下文窗口越大越好，把所有信息都塞进去就行。但实际上，无关信息不仅浪费成本，还会干扰模型对当前重点的判断，降低决策准确率。 上下文工程的核心，是在每次模型决策前，设计哪些信息进入上下文、以什么形式进入、放在什么位置、何时更新或移出，以此提高模型做出正确决策的概率。

1. 上下文工程的五类核心动作

上下文管理不是简单的 “塞信息”，而是一套精准的操作体系：

1. 写入：把目标、规则、环境、任务状态明确写进上下文，不让模型靠猜测工作。
2. 选择：从已有的候选信息里，只筛选当前步骤需要的内容放进窗口，过滤无关信息。
3. 检索：当前没有的信息，从历史会话、知识库、工具目录里按需捞取。
4. 压缩：长内容外置到文件，只保留核心结论和索引，同时清理窗口里过期、重复的内容。
5. 隔离：用独立会话或子 Agent 处理旁支任务，只把最终结果带回主线，避免污染主上下文。

2. Prompt Cache：成本优化的核心抓手

多轮对话里，每轮都带上全部上下文，全量计算的成本会非常高。而模型服务的 Prompt Cache 机制，可以缓存已经计算过的前缀内容，只计算新增部分，大幅降低成本。 要最大化缓存命中率，上下文组织就要遵循几个原则：

• 系统提示词、基础工具定义、长期规则放在最前面，保持内容和顺序稳定。
• 对话历史采用追加方式保存，不修改已发送的消息。
• 当前文件、任务进度、时间、工具结果这些动态内容，统一追加到末尾。
• 工具和 Skill 按需加载，避免每轮都重新排列完整的能力列表。

3. 渐进式加载：控制上下文规模的关键

随着 Agent 能力越来越多，工具定义本身就会占用大量上下文，还会增加模型的选择难度。渐进式加载的思路，就是默认只暴露工具的名称和简要描述，根据任务需要再加载详细的工具说明；Skill 也是同理，先看名称和描述，确认适用后再读取完整内容。 而这一切的前置环节，是意图识别：先判断用户的需求是问答、改代码、查资料还是调用外部系统，再对应加载相关的工具、Skill 和 MCP，让上下文里始终只有当前任务需要的能力。

四、Memory：让正确的历史在正确的场景复现

记忆是很多 Agent 产品的宣传点，但 “越用越懂你” 是个很模糊的说法。记忆真正解决的，是用户反复交代背景的痛点 —— 长期使用后，一些基础信息和偏好，不需要每次都重新说。 但记忆不是 “把所有聊天记录都存下来”，记忆系统的核心，是做准入判断：哪些历史信息有资格影响未来的任务。

1. 五类长期记忆

我更倾向于把长期记忆分成五类，它们的作用和影响边界完全不同：

• 稳定事实：去情境化的客观信息和长期偏好，比如用户所在城市、常用工作语言，作为长期推理的前提。
• 用户知识背景：用户的专业领域、熟悉的技术栈，用来调节解释的深度，不改变事实结论本身。
• 行为信号：从多次交互中观察到的稳定使用模式，比如用户习惯先看工作区文件再执行任务，作为交互策略的调节信号。
• 表达偏好：用户对输出风格的偏好，比如先给结论、减少空话，只控制 “怎么说”，不影响 “说什么”。
• 会话延续信息：当前会话里的目标、决策、进度、未完成项，用来延续任务进度。

2. 为什么不把 “做事方法” 放进长期记忆

上面这五类都属于陈述性记忆，记录的是 “是什么、发生过什么”。还有一类程序性记忆，也就是 “做事的方法步骤”，我不建议放进长期记忆里。 原因很明确：

• 局部经验不具备通用性，一次任务里有效的步骤，换个场景可能就不成立。
• 会干扰模型推理，让模型复用历史步骤，陷入局部最优，而不是根据当前证据选择路径。
• 程序性内容本质是动态的系统提示词，但缺少版本管理、评审和回滚机制，不可控。
• 没有稳定的评估机制，无法判断 Agent 是在优化，还是在积累偏见。 更合理的做法是：把经过验证的工作方法沉淀为可版本化、可评审、可测试、可回滚的 Skill，按需加载；用户事实和历史状态，才放进 Memory。

3. 记忆的作用域分层

记忆不是全局生效的，作用范围越大，写入的门槛就应该越高：

• 当前轮临时上下文：只生效于当前一步操作，任务结束就失效，比如刚选中的代码、上传的文件。
• 会话级记忆：在一次对话内有效，比如任务进度、已调用的工具，会话结束后归档。
• 项目级记忆：在某个工作区 / 项目内生效，比如架构约定、团队决策，项目变更后随之更新。
• 用户级记忆：跨所有项目生效，比如长期表达偏好、职业背景，用户可手动修改或删除。
• 团队级记忆：组织内共享，比如团队流程、内部术语，随组织制度更新。

五、Harness Engineering：构建稳定可控的执行体系

上下文工程解决的是 “Agent 信息够不够” 的问题，但当 Agent 真正开始写文件、跑命令、操作系统时，更关键的问题出现了：执行方向对不对？危险操作谁来拦？多个能力怎么协同？ 这些问题，都要靠 Harness Engineering 来解决。Harness 本意是套在马上的整套装备，放在 Agent 里，就是一套引导、约束、整合的控制系统。

1. Harness 的三类核心能力

从词源出发，Harness 对应三类核心能力，刚好解决三个维度的问题：

• 驾驭（Steer）：控制执行的方向、节奏和停止时机。比如系统提示词和规则文件定义工作原则，Skill 规定任务步骤，任务清单拆解大目标，错误提示给出纠正方向，让 Agent 不跑偏、不卡住。
• 约束（Constrain）：防止执行超出安全边界。比如权限管控、沙箱隔离、危险操作人工审批、命令白名单 / 黑名单，还有测试验证、回滚机制、审计日志，把风险锁在可控范围内。
• 整合（Integrate）：把各项能力组织成协同的系统。比如工具、MCP、记忆这些执行能力，子 Agent 协作、钩子机制、自动化触发这些协作机制，让各项能力有序配合，而不是零散堆砌。

这三者缺一不可：只有引导没有约束，会出现越权操作；只有约束没有反馈，出错后无法自我修正；能力多但缺少编排，长任务很难稳定跑完。

2. 五层 Harness 架构：构建者视角

一套完整的 Harness 体系，从下到上可以分成五层，形成 “前馈引导 — 执行 — 反馈纠正 — 编排 — 迭代” 的闭环：

第一层：运行环境层

这是 Agent 执行的基础，用户通常感知不到，但缺一不可。包括文件系统、Shell 执行环境、沙箱、浏览器、MCP 连接，还有权限边界、审批闸门、操作白 / 黑名单。 可以说，文件系统是 Agent 最基础的运行环境，它支撑了持久状态、跨会话工作和多 Agent 协作，所有上层能力都建立在这个基础上。

第二层：引导层（前馈）

在 Agent 执行前，就给它提供必要的信息和约束，提高第一次就做对的概率，这就是前馈控制。 引导的内容包括：项目上下文（项目概况、目录结构、关键依赖）、运行环境信息（操作系统、Shell、时间时区）、规则与风格约束、工具使用规范、Skill 与规则文件，还有上下文结构的优化。 前馈的核心目标，是让 Agent 在动手之前，就清楚 “我是谁、我能做什么、按什么规则做、当前环境是什么样”，减少盲目试探。

第三层：反馈层

Agent 执行后，要把结果和错误信息准确返回，让它能自我纠正，这就是反馈控制。 反馈分两类：一类是计算型反馈，比如语法检查、类型检查、单元测试、构建结果，成本低、速度快、结果确定，优先用这类信号做快速校验；另一类是推断型反馈，比如代码审查、架构评估、需求匹配度判断，需要模型做语义判断，成本更高，放在靠后的检查阶段。 好的反馈不是只丢一个错误码，而是要告诉 Agent 错在哪、怎么修正、能不能重试。比如文件不存在就提示搜索路径，编辑失败就提示重新读取文件，权限不足就提示请求用户确认。

第四层：编排层

负责组织多个能力、分配不同角色的职责。比如意图识别与路由、多模型路由、多 Agent 协作、并行工具调用、渐进式加载，都是编排层的工作。 编排层的核心，是让合适的能力在合适的时机出现，让不同的 Agent 各司其职，而不是所有能力、所有任务都堆在一个主 Agent 上。

第五层：迭代层

Harness 不是一次性配置完就完事的，它需要随着模型能力、业务场景和问题反馈持续调整。 常见的迭代方式包括：模型能力提升后，精简冗余的上下文引导；出现新的错误模式时，补充对应的约束；针对不同模型适配不同的工具组合；针对高频出现的问题，补充对应的机制。 迭代要讲证据，单次偶发问题不用急着改规则；新增机制也要评估副作用 —— 更严格的审批会降低风险，但也会打断流程；更多的规则会更规范，但也会占用更多上下文。

3. 使用者视角：如何搭建自己的 Harness

对于使用 Agent 的团队来说，不需要从零搭建整套 Harness，但可以从四个维度入手，让 Agent 在自己的业务里更靠谱：

• 上下文工程：用规则文件把项目架构、依赖规范、代码风格写清楚，大变更先写规范文档，把高频流程做成 Skill 或快捷命令。
• 架构约束：把团队的代码规范、架构规则接入本地检查、Git 钩子、CI 门禁，确定性问题交给程序检查，语义问题再交给审查 Agent。
• 反馈循环：每次编辑后做快速检查，把 CI 结果、构建日志返回给 Agent，让它能基于验证结果自我修正。
• 熵管理：定期扫描规则和代码的一致性，处理历史债务、失效文档、过期依赖，避免规则和代码慢慢脱节。

六、Loop Engineering：让任务进入长期运行循环

前面讲的都是单次任务怎么做好，而 Loop Engineering 关注的是更长期的问题：任务怎么被触发、怎么连续执行、怎么验证结果、怎么记录进度、怎么再次运行 —— 把 Agent 从 “单次对话工具” 变成 “可长期运行的任务系统”。

1. Loop 不是 “设个目标” 就行

很多人觉得给 Agent 设个长期目标就是 Loop 了，其实不是。目标只定义了 “要去哪里”，但一个完整的 Loop，还需要触发器、独立执行环境、工具、验证信号、停止条件。 一个可用的 Loop 至少包含这些组件：触发器、独立工作空间、Skill 与工具、子 Agent、持久化状态、评估传感器、停止条件与预算控制。 举个简单的例子：每日依赖安全检查。每天定时触发，创建独立的工作空间，读取更新规范，查询漏洞和可用更新，修改依赖文件，运行测试和扫描，失败就尝试修正，成功就生成 PR 草稿，最后记录本次结果和交接信息 —— 这才是一个完整的 Loop。

2. Loop 的边界：它不是万能的

Loop 能大幅提升重复任务的效率，但它解决不了所有问题：

• 它不会自动产生正确的目标，目标错了，循环只会更快地朝错误方向跑。
• 它不会自动产生可信的验收标准，如果执行和验收共享同一个误解，就会出现 “错误的实现 + 全绿的测试”。
• 它不能承担责任，发布、支付、用户数据这类高风险操作，必须有明确的人类负责人和审批边界。
• 它替代不了人的判断，探索性、创新性的工作，还是要由人主导。

七、落地的现实边界：没有银弹，只有系统工程

聊了这么多工程方法，也要清醒地看到 Agent 产品化的现实边界，避免过度理想化。

1. 业务正确性的验证缺口

现在的 Harness 实践，大多集中在代码质量、架构规范、可维护性上，但对功能和业务正确性的验证，还没有成熟的规模化解法。 原因很现实：需求本身很难被完整描述，功能组合后的边界行为往往没有定义；同一个 Agent 既写实现又写测试，对需求的理解偏差会同时带入两边；很多业务判断没有可计算的标准，只能靠人确认；而业务错误的成本，远高于代码风格问题。 所以，业务风险越高，AI 的自治度就应该越低：一次性脚本、内部工具可以给高自治度；跨系统改动、公开 API 要中等自治；核心业务逻辑（支付、风控、订单）就要低自治，以人工审核为主。

2. 老系统的 Harness 建设难度

不是所有系统都适合快速上 Agent，代码库本身的 “可驾驭性”，直接决定了建设难度。 老系统往往结构混乱、边界模糊、缺少测试、历史债多，Agent 理解起来困难，规则也很难落地 —— 全量修复成本太高，大量白名单又会失去意义。 更务实的做法是：先梳理模块边界、补齐关键链路的测试和观测，再上 Harness；优先在结构清晰、修改频繁、价值高的子模块验证，再逐步扩展；先约束新增和修改的代码，再慢慢治理存量。

3. 人永远是最终的责任人

Harness 和 Loop 能覆盖重复、确定、可验证的工作，但方向选择、标准定义、责任承担，永远是人来做的。 AI 可以提升执行效率，但团队不能因此放弃对代码、逻辑、架构的理解。当循环自主运行时，最危险的就是人不再有自己的判断，把所有结果都当成理所当然。

最后：两个核心结论

聊到最后，其实 Agent 产品化的核心逻辑可以总结为两句话： 第一，模型决定了能力的上限，但上下文和 Harness 决定了这个上限能不能稳定落地。只堆模型能力，做出来的永远是 Demo；只有配上完整的工程体系，才能变成可用的产品。 第二，人负责选择方向、定义标准、承担责任，Agent 负责执行、验证、加速迭代。两者不是替代关系，而是互补关系 —— 把重复的事交给 Agent，把判断的事留给人。

Agent 的产品化，从来不是单点的优化，而是一套系统工程。从模型到上下文，从执行管控到长期循环，每一层都做扎实，才能让 Agent 真正从 “看起来很酷” 变成 “用起来靠谱”。