跳转至

垂类业务如何落地生产级 Agent（阿里技术）

📊 Level ⭐⭐ | 12.4KB

阿里技术（孙敦灿，2026-09-16，第一方 9 篇连载中的第 60 篇）给出的企业落地清单式长文：把 Agent、Loop-Engineering、Skills、Harness、LLM-Wiki、RAG、Memory 这些同期涌入的热词，统一还原成「从 Demo 到生产」需要逐项回答的工程问题。全文主张一句话：Vibe Coding 与可视化平台降低的是「从想法到 Demo」的成本，几乎不自动降低「从 Demo 到生产」的成本，后者是系统工程。

核心命题：名词会换，能力问题稳定

作者给出的第一原则是不要「把新名词当架构本身」（今天上 Agent Loop、明天换 Agent Graph、把知识库改名 LLM-Wiki）——名词在变而系统没有变稳；正确做法是把热词还原成它真正解决的工程问题。

概念（会换名字） 真正解决什么 生产里落到哪一层
Loop 路径不预设时，用「观察—行动—修正」的隐式循环驱动多步 动态选工具的运行时
Checkpoint 与 Loop 强协作：运行进度持久化 暂停、续跑、跨进程恢复
MCP 用统一协议接入数据和工具 工具接入标准
Skills 把流程经验封装成可发现、按需加载的能力 能力目录与版本治理
Harness 模型外围的「操作系统」：工具、沙箱、权限、预算、评估 运行时
LLM-Wiki 摄入时把原文编译成可引用的结论，而非查询时临时阅读 知识编译层
RAG 检索时找回相关原文或证据 检索与知识层
Memory 跨轮、跨会话保留必要信息 事实／经验／进度的分层

行文把 2026 年业界共识收成一条公式「Agent = 模型 + Harness」——模型提供智力，Harness 是让智力安全作用于世界的操作系统；企业不必照搬任何一家 SDK，但公式背后的问题必须自己回答。

入口选择：四道关与最小闭环的五个问题

生产落地失败往往不在模型能力，而在入口选错。作者主张切入点同时满足四条件：高频（每天发生，样本足够评估与改进）、低风险或风险可隔离（出错可逆，不立即造成资金与合规损失）、规则相对明确（有 SOP／知识库／可调用系统数据）、闭环短（受理到完成路径清楚，「做完了」容易定义）。公开案例被用来佐证：Klarna 最先规模化的是退货、退款、支付发票类高频会话，而不是把纠纷裁决一次性交给模型——其 2026 年的公开形态是「AI 处理约三分之二常规问询，复杂、高情绪、高价值问题交回给人」的混合模式。

边界治理采用可叠加的三档，不必一次到位：先用 A 避免做错场景，再对写操作上 B，最后把投诉、退款、政务办理等红线场景做成 C。目标则要写成可验收的规格，而不是产品愿望。

知识层：从查询时编译到摄入时编译

这是全文与 Karpathy LLM-Wiki 模式衔接最紧的一章。传统 RAG 的失败形态是查询时编译（Query-time Compilation）——每次提问再从原始文档临时拼凑；LLM-Wiki 的关键差异是摄入时编译（Ingest-time Compilation）：知识只被整理一次，然后持续增量更新，每次查询消费的是已经编译好的知识。

把个人 Wiki 模式搬到企业垂类业务需要三层适配：来源从个人收藏变成产品手册／合规文件／SOP／工单／会议纪要／数据库 schema；更新频率随业务变更与规则更新；权威性必须有来源链接与生效日期；并补上多租户、多角色权限与「知识变更需审批、留痕、可追溯」的合规约束。

日常工作被收成三个必须拆开的动词——Ingest（摄入）、Query（取用）、Lint（体检）：摄入负责把资料变成可引用结论，取用负责按场景拿到正确版本，体检负责定期找出矛盾、断链、过期和空白；「没有取用，编译只是给自己看；没有体检，编译只是把噪声换了个存放处」。

Ingest 的七条实践要点（企业化改造后的可重复编译作业）：原文只追加不改写（原始文档是事实源，Wiki 是解释层）；先立契约再写内容（页面类型、必填元数据、章节顺序先定死，否则 Lint 没有门槛）；编译输出是补丁不是整页重写（防「摘要越来越漂亮、细节越来越空」的坍缩）；标明抽出与推断（模型推断必须打标，推断占比高的不能当政策用）；概念页要有门槛（至少被两篇原文引用才独立成页）；日志可被机器读（统一前缀如 ## [2026-04-02] ingest | 退货政策-v3，让 grep 能拉出审计时间线）；机械活交给脚本、认知活交给模型（去重／命名／状态机／frontmatter 校验用脚本，摘要／实体归并／冲突标注用模型）。

能力层与循环层

4.2 的「能力封装分档」主张技能不是一段 Prompt：目录层只放 name + description（约百 token），命中后才加载 SKILL.md 正文，必要时再打开附录与脚本——即渐进式披露（Anthropic Agent Skills 的做法）。一个垂类能力单元至少包含触发条件、输入要求、执行步骤、工具白名单、校验规则、异常处理、输出约束；工程上要求「一 Skill 一事」（正文超约 5000 token 就该拆）、版本可回滚（skill_version 出现在轨迹里，出问题切回旧版而非热改 Prompt）、独立评测（退货 Skill 看工具成功率与错误承诺率）、以及把 name/description 当接口定义（Agent 只看这两字段决定是否触发）。实践中的有效组合是「B 或 D 做主路径骨架，C 做可复用的场景包，A 只留全局红线和人设，E 负责把线上打法回流成下一版 C」，并且 Tool 始终按当前 Skill 的白名单暴露（4~8 个），而不是把企业 API 目录全量摊开。

循环层的边界被点得很硬：循环里真正执行工具的是外围代码，不是模型——模型只能发出 tool_use，应用把工具跑完再把结果塞回去；生产级 Agent 的控制权从第一天起就应该在这段确定性代码上。三种形态的对照是：一次生成（没有下一步）／固定自动化（预先写死的节点，只能走已画的边）／Agent 循环（下一步由当前状态 + 规则/模型决定，可以改计划再行动，完成条件被独立验证）。

循环方案分四档（A 单轮检索生成／B 受控内循环／C 把循环画成可审查的图／D 确定性主链 + 局部循环）。两条常被忽略的警告：方案 B 的价值在退出条件，不在转得更多（最低清单＝步数上限、整段超时、费用预算、写操作幂等、相同参数重复调用熔断、工具结果按业务 schema 校验，「缺这几项的 Loop 只是在用 token 换偶然成功」）；方案 C 并不自动更安全（没有持久化，图与循环一样进程一丢就得从头来；没有独立验收，图只是把假完成画成「已到达结束节点」）。作者认为 D 往往是生产形态：能预定的节奏不要交给临场发挥。

接入层：工具网关而非直连

「没有系统接入，Agent 只能解释世界；有了接入却没有控制面，它会改写世界。」直连 API 的五种代价被逐条列出：身份冒用（模型用服务账号打了用户不该打的接口）、幂等缺失（超时重试造成重复创单、重复扣款）、部分失败（工单成功但通知失败、库存未锁，循环按「失败」再来一次）、schema 与错误码不稳（把降级文案当业务结果、把可重试错误当终态）、工具集过大（一次暴露上百 API，选错漏传越权概率一起上升）。

接入方案分四档（A 直连／B iPaaS 连接器／C MCP／D 工具网关），并给出全文最好记的类比：MCP 是「USB-C 接口」，解决怎么连；工具网关解决能不能连——MCP 让工具描述与调用标准化、多个运行时可复用同一组 server，但生产仍要在协议之外做鉴权、配额、审计，协议不替代业务级 PEP。方案 D 的最低配置：调用身份与用户身份绑定、按场景的工具白名单、JSON Schema 校验、幂等键、超时与熔断、结构化错误（可重试／不可重试／需人工）、写操作默认最小权限且高风险走审核。补偿策略要预先写清：可撤销的配补偿接口、不可撤销的必须前置确认、重试必须带同一幂等键——做不到这三条就不应把执行权交给 Agent（给解释权可以，给写系统的权必须另算）。

接入真实系统后治理要求整体提升，代码执行能力还要额外沙箱隔离：文中以 Dify 平台 API 模式下 Skills 运行在无网络访问的沙箱容器、不允许运行时安装包为例说明「生产可用的安全策略」，并对照 WorkBuddy 的本地桌面执行模式（敏感文档不离开本地）。

状态层与上线后

6 之后的章节把长任务拆成三件常被混为一谈的东西：Context ≠ Memory ≠ State，并主张支持断点续跑（任务常常跨轮次）。上线后要面对漂移与评测错位，评测必须分层，并把「自进化」作为一条独立议题处理。

与本 wiki 的关系

可迁移要点

  • 选型会：需要决策时用 Agent，常规工作流用自动化，简单检索用助手——反向读即警告「把 RPA 能稳定干完的事硬做成多轮推理，既贵也不稳」。
  • 循环设计的验收问题不是「转得更多」，而是「退出条件是否齐全」。
  • 知识层的第一性问题不是召回率，而是「编译发生在摄入时还是查询时」。
  • 给 Agent 写系统的权力，必须与解释权分开治理。

→ 原文存档