正在加载，请稍候
跨平台 AI Agent 工程化的重心不在每个端上，而在技能层。用三层收敛加 Anthropic Labs 团队机制复盘，讲清技能层复用与双周评审怎么落地。
一家跨境电商客户在 2026 年初提出一个今天看来很普通的需求：同一个售后助手，要同时跑在 Web 站点、微信小程序和企业微信机器人里。我们最初的方案是三端各写一套独立实现——各配提示词、各接工具、各调模型。三个月后维护成本开始失控，才回头做统一。这篇复盘想讲一件反直觉的事：跨平台 AI Agent 工程化的重心，从来不在每个端上。
2026 年 QCon 上海站把大会主题定在「Harness AI 时代的工程实践」，讨论方向从单点模型技巧转向 Agent Runtime、AI Infra、安全可观测与端云协同。InfoQ 在介绍议程时留了一句话：模型决定 AI 能做什么，系统决定 AI 能否真正创造价值。这句话基本概括了今年企业侧的处境。
多数团队已经跨过「能不能做出一个 Agent」的阶段，卡在「让同一套能力稳定出现在所有触点」的阶段。用户今天在网页问一句，明天在小程序问同一句，后天在企业微信里再问——如果每个触点背后是不同的实现，差异会从响应文案蔓延到业务结果。跨平台不是 UI 层的事，它要求 Agent 本身被当作一套可多端部署的系统来设计。
我们见过不少技术负责人把预算花在「再训练一个更好的端侧模型」上，结果发现瓶颈从来不在模型，而在运行时、上下文、工具接入和评测这一整条工程链。InfoQ 近期另一篇报道也印证了这个判断：技术本身已经够用，企业真正落不了地的是组织与工程方法。小程序场景的体会也类似，最缺的不是模型，是能判断 AI 答案的工程师；到了多端，这种判断力必须沉淀成共享评测用例，我们在这篇里展开过：小程序 AI 应用最缺的不是模型，是能判断 AI 答案的工程师。
阿里 Open Code Review 的做法给了我们重要参照：用「确定性工程 + Agent 协同」，把通用 Agent 收敛成适合具体场景的垂直 Agent。分享里提到五类实践——分治并发、精准定位、规则模板引擎、工具链蒸馏、上下文分层管理，背后是同一个原则：确定性的工作交给工程系统，语义理解才交给大模型。这套原则放到跨平台场景，我们收敛成三层结构。
| 层 | 回答的问题 | 典型内容 | 变化频率 |
|---|---|---|---|
| 技能层 | 助手能做什么 | 工具与 MCP 服务、知识库、评测用例 | 低，最值得沉淀 |
| 编排层 | 一次任务怎么走 | 任务规划、状态机、上下文分层、兜底策略 | 中，随业务调整 |
| 端适配层 | 这个端如何呈现 | UI、事件、权限、上下文裁剪、流式格式 | 高，但必须保持薄 |
技能层与协议绑定、与端无关。我们把每项能力注册成一份技能清单，端上不直接调模型，而是调同一套运行时暴露的接口。编排层承载业务状态机与上下文分层管理——同一个查物流任务在 Web 端的上下文可以很长，在企业微信里就必须压缩，裁剪规则放在端适配层而非散落在提示词里。
效果最直接的信号是接新端的速度：从「重写一套」变成「写一个适配器」。阿里在分享中给出过生产侧规模——内部两万多名开发者使用、百万真实任务验证——说明这类收敛不是实验室技巧，而是在真实流量下被验证过的工程路线。
收敛之前，我们为三端各维护了一套提示词与工具接入。问题在第二个月集中爆发。第一，模型升级一次，三处提示词、三套工具说明全部要回归；第二，行为漂移——同一个「查物流」意图，在 Web 端命中工具 A，在企业微信里命中工具 B，返回格式对不上；第三，排障时要同时打开三个上下文，根因经常查不到底。
我们一开始以为问题是提示词写得不好，后来发现是架构问题：能力被绑死在端上。改造时我们没有推翻重来，而是先把三端共用的工具抽成一份技能注册表，再为每种能力补一套跨端共享的评测用例。凡是通过评测的改动才允许发到任意一端。
这条教训也解释了为什么我们后来坚持：跨平台工程化要先做减法，把「每个端各养一套」的隐性成本算进立项口径。很多项目的 ROI 算出来是负的，不是能力不行，是重复建设太多。移动端落地时我们算过一笔真实成本账，口径和这里一致：AIcoding 移动端落地，我们算了一笔真实成本账。
团队能力建设这件事，Anthropic 内部 20 人的 Labs 团队是一个值得拆解的样本。InfoQ 报道称，Claude Code、MCP、Claude Design 都出自这个团队，而它的项目成功率只有 20% 到 30%。它用三个机制维持这种低失败成本：每两周做一次「继续还是转向」的评审；项目一旦超过 4 人就从 Labs 毕业进入正式产品团队；负责人只对结果负责，不承担传统人事管理。
这套机制映射到我们的交付团队，有三点直接可用。
对多数企业而言，跨平台 Agent 工程化真正的门槛不是招不到会调模型的人，而是没有把「能力建设」和「项目交付」分开管理。技能层若随项目临时组队、项目结束即散，下一次启动又得从零开始。关于怎么把这类团队拆成可复制的阶梯，我们单独写过一篇：企业 AI 编程转型：移动端团队能力建设的四个阶梯。
以上七项，前两项决定架构是否健康，后五项决定团队能不能长期维持。逐条过一遍，通常半小时就能看清自己卡在哪一层。
不一定，但技能层需要一个统一的能力描述协议。MCP 是当前生态里最主流的方案，好处是工具说明、鉴权、调用方式可以标准化；若现有系统已有成熟的内部协议，也可以先用它收敛，再把网关层逐步向 MCP 对齐。
短期会多一层抽象，长期是省时间的。关键是把端适配层做薄、把评测前置。第一次收敛通常需要一到两周补齐注册表与评测用例，之后每接一个新端都能省下按周计的重写成本。
有一个简单判据：当同一个能力要在两条以上产品线重复实现时，就该开始收敛，哪怕团队只有三四个人。收敛初期只抽公共工具与共享评测，不要一上来就设计平台。
当各端业务意图几乎不重叠、各自是独立闭环时，统一只会增加抽象成本。先让每个场景跑通、跑出真实调用数据，再决定哪些能力值得上升到技能层。
跨平台 AI Agent 工程化的答案，不在任何一份框架文档里，而在你对自己技能清单、编排方式和评审节奏的诚实盘点里。如果你正卡在「三端三个 Agent 各跑各的」，可以先带着已有的技能清单来聊聊——蓝曜炬辉提供从架构评审到多端落地的 AI Agent 交付支持，入口在联系页；想看同类项目怎么从三层收敛里拆出来，可以翻案例页。