模型之上，工程为先：Agent 从会写代码到可控交付

模型之上的 Agent 工程与架构海报

前记：上周末参加了一个腾讯云架构同盟组织的技术沙龙，主题是 Agent 工程和架构。现场有大几百号人，也是我第一次到腾讯滨海大厦，到了之后发现排队的人好多好多，大家对学习、使用 AI 智能体的热情还是很高涨的。

我自己也希望多去了解一下，现在大家到底是怎么架构、开发和使用智能体的。一方面评估下自己在工作和生活中使用智能体的方向和姿势是不是合理，另一方面也及时看看有没有新的概念和实践出现。

比如这次提到的 MetaSkills，就是我之前没有系统了解过的概念，后面也准备继续去研究和尝试使用。

听完几场分享后，一个比较强的感受是：现在关于 Agent 的讨论，不能只停留在模型能力本身，比如模型是不是更聪明了，工具调用是不是更稳定了，代码写得是不是更快了。真正决定 Agent 能不能进入生产环境的，往往不是模型本身，而是模型之上的工程体系。

换句话说，Agent 的核心公式不是单纯的“大模型 + 提示词”，而更接近：

Agent = Model + Harness 生产力 = 模型能力 x 工程体系

模型之上的 Agent 工程总览

模型提供智能，Harness 提供约束、流程、工具、验证和治理。人类负责设定方向，Agent 负责执行任务。真正的难点，是如何让这个执行过程可控、可复用、可检查、可演进。

这也是这次分享中最值得关注的主线：Agent 正在从个人外挂，走向团队级、企业级的软件工程基础设施。

一、差距不在模型，而在 Harness

张善友老师在分享中提到，从 Harness Engineering 到 MetaSkill，本质是在回答一个问题：如何把模型的不确定性，放进一个确定性更强的工程系统里。

Harness 可以理解为包裹在模型外部的一整套工程壳层。它不只是“给模型接几个工具”，而是把意图、上下文、工具、编排、护栏、审批、验证和可观测性放在一起，形成一套让 Agent 稳定工作的基础设施。

一个更完整的 Agent Harness，至少应该包括：

1. 意图层：把自然语言需求规格化，让 Agent 明确“要做什么”和“验收标准是什么”。
2. 上下文层：管理任务目标、背景知识、代码库地图、历史状态和已经踩过的坑。
3. 工具层：让 Agent 能调用浏览器、代码执行器、文件系统、数据库、API、MCP 等外部能力。
4. 编排层：把分析、设计、开发、评审、测试、归档这些动作组织成可流转的状态机。
5. 护栏和审批层：管理权限、风险操作、人工卡点、自动化拦截和高级操作熔断。
6. 验证和可观测层：对产出进行自动化测试、页面验收、回归检查、代码审查，并记录过程、决策和失败原因。

这背后是一种控制论思维：用确定性约束不确定性。

对比之前参加的“多智能体协同驱动软件研发”培训，我对 Harness 的理解又更具体了一点。培训里把 Harness 落地拆成四层防线：Rules、Skills、Agents + Workflow、Scripts。

Rules 是软约束，用来告诉 Agent 基本规矩；Skills 是标准操作手册，把构建、验证、代码审查、E2E 测试这些固定步骤沉淀下来；Agents + Workflow 负责角色分工和流程接力；Scripts 则是硬门禁，靠脚本检查来决定能不能交付。

这几层其实是在逐步收紧约束：从“告诉它应该怎么做”，到“教它按步骤做”，再到“让不同角色互相制衡”，最后到“用脚本判断是否通过”。这比单纯写一大段提示词要可靠得多。

大模型本身有创造性，也会有幻觉、遗漏和反复犯错。工程体系的作用，不是消灭这种不确定性，而是把它限制在可观察、可回滚、可验证的范围内。

二、MetaSkills：把 Skill 编排成可复用工作流

这次讨论中最重要的关键词之一，是 MetaSkills。

普通 Skill 更像是 Agent 的单项能力，比如读取文件、生成页面、运行测试、调用浏览器、整理文档。MetaSkill 则是更高一层的抽象：它把多个 Skill、工具、检查点和结果汇总步骤，封装成一个可复用、可检查的 DAG 工作流。

可以简单理解为：

Skill 是能力单元，MetaSkill 是面向能力单元的工作流产品抽象。

这和 LangGraph 的关系也很值得区分。

LangGraph 是底层图运行时，负责状态流转、节点执行、循环、持久化、人工中断和故障恢复。MetaSkill 则更偏业务编排描述层，定义“哪些 Skill 如何组合，形成一个可交付的工作流”。

也就是说：

MetaSkill 定义组合方式，LangGraph 负责可靠运行。

MetaSkill DAG 工作流

单独使用 LangGraph，开发者往往需要自己实现 Skill 注册、发现、加载和适配。单独使用 MetaSkill DAG，又可能在复杂循环、状态持久化、人工介入和故障恢复上不够强。

更合理的企业级架构，是用 MetaSkill 作为业务编排层，用 LangGraph 作为执行引擎。前者让业务流程标准化，后者让执行过程工程化。

对于企业来说，这一点非常关键。因为团队真正需要的不是一个“聪明但不可控”的 Agent，而是一套可以被沉淀、复用、审计和治理的数字工作流。

三、数字员工：本体驱动 + 元技能编排

另一个重要方向，是数字员工。

分享中提到，一个“好雇”的数字员工，核心在于三件事：

1. 本体驱动。
2. 技能编排。
3. 数字员工自洽。

本体系统可以通过 OWL、REA 本体论、JSON-LD、SPARQL 等方式定义业务世界里的对象、关系、规则和语义。它的价值在于，让 Agent 不只是“读懂一句话”，而是能在一个结构化的业务世界中行动。

但本体驱动的数字中台落地并不容易。完整本体往往太重，直接进入应用会遇到建模复杂、工程成本高、模型不友好等问题。

更现实的路径，是从应用场景出发，对本体进行切片和投影，再通过 JSON-LD 这种更适合工程传递的序列化格式，把本体对象映射到具体 Skill。

这条路径可以概括为：

从业务场景出发，做本体切片； 从本体切片出发，映射 Skill； 再通过 MetaSkill DAG，把 Skill 编排成可执行工作流。

这也是数字员工和 Harness 融合的关键。

Harness 提供敏捷落地能力，本体系统提供形式化和企业级治理能力，MetaSkill 则把业务动作组织成稳定流程。三者结合，才更接近真正可用的 AI 工程化方案。

四、AI Coding Agent：从写代码到交付系统

储诚益老师的分享，把焦点放在 AI Coding Agent 的团队化应用上。结合之前笔者参加多智能体协同研发培训来看，我觉得 AI Coding 的关键转变可以概括为一句话：

从“让 AI 帮我写代码”，变成“让 AI 在 Harness 里交付一个可验证的系统变更”。

过去很多人使用 AI Coding 的方式，是把它当成个人外挂：让它补函数、写页面、改 Bug、解释代码。这个阶段的价值已经很明显，但也有天花板。因为一旦进入团队生产流程，真正的问题就不只是“代码能不能生成”，而是“需求有没有理解对、方案有没有评审过、实现有没有跑通、测试有没有覆盖、风险有没有被拦住”。

培训里总结过一些 Agent 失控时经常出现的问题，我觉得非常真实：虚报进展、约束规避、降低标准、上下文失忆、跳过步骤、伪造验证、错误死磕、小题大做。

这些问题在实际使用 AI Coding 时都可能遇到。比如 Agent 说“已经验证过”，但其实没有跑关键命令；看到测试失败，不修业务逻辑，反而改测试；用户只是想补一个字段，它顺手升级依赖、重命名接口、改表结构；长会话一压缩，又把之前否决过的方案拿出来重做。

所以，AI Coding 的关键不是“让 Agent 多写代码”，而是建立一套协作管理机制。

分享中提到人机协作有四个不对称：

1. 速度不对称。
2. 语义不对称。
3. 信任不对称。
4. 状态出轨。

这四个不对称，可以和培训里的 Harness 框架对应起来看。

速度不对称，需要靠小 PR、阶段性卡点和自动化验证来消化。Agent 写代码很快，但人类 review 跟不上，所以每次 PR 最好控制在可审查范围内，比如不要动不动超过 5000 行。

语义不对称，需要靠需求规格化来解决。培训里提到的 SHALL + GWT 格式就很有启发：SHALL 描述系统必须具备什么能力，GWT 用 Given / When / Then 写清楚验收场景。这样需求和测试用例之间的翻译成本会低很多。

信任不对称，需要靠独立验证来解决。不能让写代码的 Agent 自己宣布合格，代码审查、测试验证、E2E 验收最好由独立角色完成。写代码的人不能自己判合格，判合格的人也不能自己改代码。

状态出轨，需要靠工作流和上下文工程来解决。比如用 specs/ 做系统能力的 Source of Truth，用 codebase-guide/ 做模块化知识地图，用任务文档记录每一步产出，让 Agent 知道现在做到哪、改过什么、哪些结论已经确认过。

从这个角度看，Harness 不是 AI Coding 的外围辅助，而是 AI Coding 能进入团队生产环境的前提。没有 Harness，Agent 很容易变成一个速度很快但不稳定的代码生成器；有了 Harness，它才有机会成为研发流程里的稳定执行节点。

另一个关键判断是：代码审核需要比写代码更高一个 level 的大模型。

写代码可以由成本更低、速度更快的模型完成，但审查代码需要更强的推理能力、上下文理解能力和风险识别能力。AI Coding 的生产化流程，不应该只关注生成模型，也要关注验证模型和审查模型。

五、前后端开发智能体：多角色协同 + 验证闭环

关于前后端开发智能体，我现在更倾向于把它理解成一套多角色协同流程，而不是一个“全能开发 Agent”。

培训里的一个例子是把研发流程拆成多个专业 SubAgent：需求分析师、方案架构师、后端工程师、后端审查员、后端测试员、前端工程师、前端审查员、前端测试员。这个拆法和这次沙龙里讲的前后端 Agent 协作流程可以对上。

也就是说，一个相对完整的开发智能体系统，至少要覆盖需求、方案、实现、审查、测试这几个角色。复杂一点的场景，还需要 PM Agent 做调度，决定什么时候进入下一棒、什么时候打回上游、什么时候停下来让人确认。

这比“一个 Agent 从头写到尾”更麻烦，但也更接近真实研发流程。因为真实研发里，本来就不是谁写完谁说了算。

前后端 Agent 协作流程

以前端为例，一个相对理想的流程可以是：

1. 需求分析 Agent 先读取需求，整理用户目标、页面范围、核心流程、边界条件和验收场景。
2. 方案设计 Agent 生成线框图或页面结构，明确布局、信息层级、交互组件和接口依赖。
3. 数据结构 Agent 把页面所需字段、状态和接口依赖整理成 JSON Schema、Mock 数据或 API 契约。
4. Frontend Agent 基于设计和结构化数据实现页面。
5. Frontend Reviewer 检查组件设计、类型安全、性能和样式一致性。
6. Frontend Tester 使用 Playwright 执行组件测试和 E2E 页面验收。

这里有一个很重要的细节：JSON 数据结构化的准确性通常比 Markdown 更高。

Markdown 适合表达说明和讨论，但在 Agent 协作中，结构化数据更适合作为流程交接物。比如页面结构、字段定义、接口返回、组件属性、校验规则，用 JSON 表达会更稳定，也更容易被程序检查。

后端也类似，只是它更强调业务语义、数据模型、接口契约、权限规则和运行时验证。一个后端开发智能体不能只会写 Controller 或 Service，还要能理解业务对象、状态流转、异常场景、事务边界、幂等控制、权限校验，以及日志和可观测性。

也就是说，前端 Agent 更关注“从产品到页面”，后端 Agent 更关注“从业务对象到接口和运行时”。两者之间真正的连接点，是结构化契约。

这个契约可以是 API 定义、JSON Schema、Mock 数据、错误码约定，也可以是组件属性、页面状态和交互事件。只要契约足够清晰，Agent 之间的协作就会稳定很多；如果契约含糊，前端和后端 Agent 就很容易各写各的，最后靠人来补锅。

培训里提到的 Propose / Apply / Archive 也很适合放到这里理解。

Propose 阶段先做需求分析、方案设计、就绪评审，形成 proposal、requirements、design、tasks 等交付物，完成后停下来让人确认。Apply 阶段再进入开发实现、代码审查、测试验证。Archive 阶段把这次变更合并回 specs/，让文档和代码一起沉淀。

这套流程的价值在于，开发不是一次性对话，而是一个变更生命周期。每一步都有输入、输出、阻塞条件和禁止事项，Agent 不能随便跨角色改上游制品，也不能发现问题后自己悄悄改需求。

AI Coding 与 Playwright 验证闭环

在这条链路里，Playwright 是一个特别关键的 Web 验收工具。

Playwright 是微软开源的 Web 自动化与端到端测试框架，可以模拟真实用户操作浏览器，验证页面功能是否符合预期。它支持 Chromium、Firefox 和 WebKit，适合做 Web 系统的功能验收、回归测试和 AI Coding 结果验证。

它之所以重要，是因为 AI Coding 的结果不能只靠“代码看起来对”来判断。一个页面是否真的可用，要看它能不能打开，按钮能不能点击，表单能不能输入和提交，路由跳转是否正确，移动端和桌面端布局是否正常，修改一个功能后有没有破坏原有流程。

这些问题靠人工肉眼检查成本很高，靠静态代码分析又不够。Playwright 刚好可以成为开发智能体的“眼睛”和“手”：打开浏览器，执行真实操作，截图，断言，回归。

一个更稳的开发智能体闭环应该是：

Agent 修改代码 -> 启动本地服务 -> Playwright 打开页面 -> 执行关键用户路径 -> 截图和断言 -> 失败则反馈给 Agent 修复 -> 通过后进入 review。

这样做的价值，是把“写代码”和“验证代码”连在一起。Agent 不只是生成一段代码，而是要在真实运行环境里证明它的修改是有效的。

如果再严格一点，验证层可以分成四类：API 测试、功能验收、回归测试、工程验证。API 测试看功能正确性、权限控制和数据校验；功能验收用 Playwright 从用户场景逐条验证；回归测试确保旧功能没被破坏；工程验证则跑 lint、unit test、build、post-verify 等硬检查。

当然，后端 Agent 更需要护栏。因为后端修改往往涉及数据、权限、资金、订单、账号等高风险对象。Agent 可以写代码，但不能无限制地操作生产环境。权限控制、沙箱环境、审批机制和操作熔断，应该成为后端开发智能体的基础设施。

所以我对前后端开发智能体的理解也做了一点修正：它不是“前端一个 Agent，后端一个 Agent”这么简单，而是需求、方案、开发、审查、测试、归档多角色协同，再通过 Harness 把这些角色放进流程、门禁和反馈闭环里。

这也是为什么平台化运行时会变得重要。

六、Agent 平台化：Runtime、Sandbox、Memory、Trace

牛赞老师分享的 EdgeOne Makers Agents，提供了另一个视角：Agent 送上生产，到底难在哪里？

从“会说话”到“会动手”，Agent 需要的不只是模型 API，而是一整套运行环境：

Agent 平台化运行时架构

1. Runtime：承载 Agent 主程序，包括 LLM 调用、循环控制和业务逻辑。
2. Sandbox：提供隔离环境，承载浏览器、代码、Shell、文件等有副作用的操作。
3. Memory：管理会话记忆、任务状态和历史上下文。
4. Trace：记录执行过程，帮助调试、审计和复盘。
5. Template：提供开箱即用的场景模板，降低开发门槛。

这种平台更像是面向 AI Agent 的 Vercel 或 Cloudflare Workers，再加上 Agent Runtime、Sandbox、Memory 和 Trace。

开发者仍然可以使用 OpenAI Agents SDK、LangGraph、Claude Agent SDK、CrewAI 等框架编写 Agent。平台负责托管部署、会话、沙箱、模型接入和可观测能力。

这里有一个很形象的说法：手脑分离。

“脑”是 Agent Runtime，负责思考、规划、调用模型和推进任务。“手”是 Sandbox，负责执行浏览器、代码、文件、Shell 等真实操作。

这个架构能让 Agent 的行动更可控，也更适合进入生产环境。

七、Agent 进入物理世界：从软件执行到空间执行

还有一个很值得展开的方向：Agent 进入物理世界。

如果说 AI Coding Agent 主要处理的是代码、页面、接口和文件，那么进入物理世界的 Agent，面对的就是灯光、门锁、传感器、摄像头、空调、窗帘、家庭空间和真实设备。

这类场景的代表，是 Aqara Studio 这样的物联网运行时。它让 Agent 不只是在屏幕里“理解需求”，而是可以把人的自然语言意图，转化成对物理空间的感知、判断和执行。

比如，一个用户说：

我准备开会，把客厅调成适合视频会议的状态。

一个进入物理世界的 Agent，不能只回答“好的”。它需要理解“视频会议状态”背后的具体动作：

1. 调暗或调整灯光色温。
2. 关闭背景噪音设备。
3. 拉上窗帘避免逆光。
4. 调整空调到合适温度。
5. 检查门锁、摄像头、人体传感器等空间状态。
6. 在执行高风险操作前请求确认。

这意味着，物理世界里的 Agent Harness 会比软件世界更复杂。

首先是感知层。Agent 需要读取传感器、设备状态、空间上下文和用户习惯。它不能只看一段文本，而要知道“现在房间里发生了什么”。

其次是动作层。Agent 的工具调用会产生真实后果，开灯、关门、调温、布防、解锁都不是简单的 API 调用。它们会影响人的安全、舒适和隐私。

第三是权限和护栏。物理设备的权限边界必须更严格：哪些动作可以自动执行，哪些动作必须二次确认，哪些动作在特定时间或场景下禁止执行，都要被明确建模。

第四是反馈闭环。软件世界里，Agent 可以通过测试结果判断任务是否完成；物理世界里，它还需要通过设备状态和环境反馈确认动作是否真的生效。比如“窗帘关闭”不能只看命令已发送，还要看设备状态是否返回成功。

所以，Agent 进入物理世界，本质上是把 Runtime、Sandbox、Memory、Trace 这一套平台能力，进一步延伸到 IoT Runtime：

Runtime 负责理解意图和规划动作； 设备系统负责执行真实动作； 传感器负责反馈环境状态； 护栏系统负责约束风险边界。

这会让 Agent 从“数字工作者”进一步走向“空间协作者”。

但这一步也意味着更高的工程要求。因为在物理世界里，错误不再只是页面错位或测试失败，而可能是误开门锁、误触发安防、错误调节设备，甚至影响人的安全。

因此，物理世界 Agent 的关键词不是“更自动”，而是“更可靠”：可感知、可授权、可解释、可回滚，并且在关键动作上保留人的最终控制权。

八、总结：Agent 工程化的关键，不是更多魔法，而是更强闭环

这次听下来，最大的一个感受可以浓缩成一句话：

未来的 Agent 竞争，不只是模型能力竞争，而是工程体系竞争。

模型能力当然重要，但当模型能力逐渐成为基础设施之后，真正拉开差距的会是：

1. 有没有稳定的 Harness。
2. 有没有可复用的 Skill 和 MetaSkill。
3. 有没有结构化的业务语义和本体映射。
4. 有没有 Playwright 这样的自动化验证层。
5. 有没有适合前后端协作的 Agent 工作流。
6. 有没有权限、沙箱、可观测和回滚机制。
7. 有没有面向物理设备的感知、授权和反馈闭环。

从个人使用 AI Coding，到团队引入 Coding Agent，再到企业部署数字员工，甚至让 Agent 进入真实空间，本质上都在走同一条路：

把模型能力，放进可控、可验证、可复用、可治理的工程系统里。

这也是“模型之上的 Agent 工程与架构”真正想解决的问题。

Agent 的下一步，不是让它更像一个聊天机器人，而是让它更像一个能被组织雇佣、管理、协作和持续改进的数字工作者，并在足够安全的前提下，成为连接数字世界和物理世界的行动者。

而这条路上，MetaSkills、AI Coding、Playwright、前后端 Agent 流程、平台化 Runtime 和 IoT Runtime，都会成为关键拼图。

利用周末休息时间来参加这样的技术沙龙，还是很有价值的。几位讲师明显也花了很多心思来准备分享，每场内容都挺精彩，不只是讲概念，也给到了不少工程实践经验和避坑指南。

整体来说，这次收获还是满满的。后面也准备继续围绕 MetaSkills、AI Coding 工作流、Playwright 验证闭环这些方向，再结合自己的工作和生活场景，看看哪些方法是真正可以落地用起来的。