垂类业务如何落地生产级 Agent

这是 2026 年的第 60 篇文章

（本文阅读时间：约 30 分钟）

前言

AI 技术迭代迅猛，Agent、Loop-Engineering、Skills、Harness 等概念层出不穷。可视化编排与 Vibe-Coding 大幅降低了 Demo 构建门槛，但从演示到企业生产环境，稳定性、可控性、可审计性及业务闭环能力仍是必须攻克的硬仗。本文将从企业落地视角出发，探讨如何让 AI Agent 从「能跑」走向「能生产」。

01 技术迭代下的 Agent 机遇

1.1 变化的加速：Agent 不再是概念

2025 年 9 月，Anthropic 将 Agent 定义为："LLMs autonomously using tools in a loop."这标志着 Agent 已从模糊热词转变为清晰的工程范式：大模型 + 工具 + 循环。

当前，国内外大模型能力百花齐放，外围工程概念如 Agent Skills、MCP 协议、A2A 协议、Memory Compaction 等日益成熟。对企业而言，模型能力、工程运行时与业务半结构化流程三者同时成熟，客服、运营、审核等场景迎来了将决策与执行交给可控 Agent 的窗口期。

窗口的本质是“把一件事从受理推到完成”所需的拼图首次凑齐；错过的代价是让竞争对手率先将高频流程转化为可运营的生产能力。

1.2 Demo 易做，生产难过四道关

Demo 阶段往往输入干净、路径单一，而真实业务面临语义歧义、工具超时、用户意图变更及合规风险等挑战。生产级 Agent 需跨越四道关卡：

关卡	追问	Demo 与生产的分野
稳定性	同一类任务在真实流量下能否可重复完成？	Demo 偶尔惊艳；生产要求第 9999 次和第 1 次质量一致
可控性	能否限制其行为？越权能否被拦住？	Demo 无越权场景；生产中自然语言禁令挡不住工具调用
可审计性	事后能否还原其依据、操作及责任人？	Demo 无需追责；生产的错误退款要能作为完整证据回放
业务闭环	能否把任务推进到业务可验收的终点？	Demo 输出漂亮文本；生产要写入真实系统并可验收

Klarna 的案例表明，先证明能接管一部分，再发现哪些不能只按成本优化，是生产级落地的典型轨迹。Vibe Coding 降低的是“从想法到 Demo"的成本，而“从 Demo 到生产”则是系统工程。

1.3 名词会换，追能力才追得上变化

不应将新名词当作架构本身，而应将其还原为解决的工程问题。2026 年业界公式：Agent = 模型 + Harness。模型提供智力，Harness 是让智力安全作用于世界的操作系统。

概念（会换名字）	它真正在解决什么	生产里落到哪一层
Loop	路径不预设时，用"观察—行动—修正"驱动多步	动态选工具的运行时
MCP	用统一协议接入数据和工具	工具接入标准
Harness	模型外围的"操作系统"：工具、沙箱、权限、预算	运行时
LLM-Wiki	摄入时把原文编译成可引用的结论	知识编译层

Gartner 分析师建议：需要决策时用 Agent，常规工作流用自动化，简单检索用助手。把 RPA 能稳定干完的事硬做成多轮推理，既贵也不稳。

1.4 从小场景切入，先闭环再扩展

生产有效的切入点通常满足四个条件：高频、低风险或风险可隔离、规则相对明确、闭环短。国内外头部企业均从高频适老事项或标准化服务切入，而非直接构建"通用大脑"。

1.5 一个最小闭环要能回答五个问题

• 用户或上游系统提出的任务，是否被正确理解？
• Agent 是否拿到了当前场景下正确的知识和数据？
• 它是否调用了被允许的能力，而不是临场发挥？
• 结果是否进入了真实业务系统，或给出可执行的下一步？
• 失败时是否有降级、转人工和事后追溯？

先把一个场景做成“可上线、可监控、可回滚、可优化”，再复用至相邻场景，是垂类业务拥抱技术变化的正确节奏。

02 先定目标，再定边界

企业用 AI 翻车往往源于目标与边界含糊。需明确五大卡点：目标打架、咨询与执行混淆、缺乏动作目录、责任无法落实、分类错误导致方案错配。

2.1 五个真实卡点

• 目标打架：提效、降本、降风险、增体验不会自动一致，需设定主次和红线。
• 混合意图：一句话里混了咨询和执行，需分段处理以避免错误承诺或越权。
• 缺乏动作目录：Prompt 里的禁令挡不住工具调用，生产需管理可执行动作目录。
• 责任缺失：责任必须设计进流程，每条轨迹需带 scene_id、policy_version 等标识。
• 分类错误：该走规则引擎的走了多轮推理，该转人工的却在循环里重试。

2.2 目标写成可验收的规格，边界按风险分级

可执行目标应包含对象、场景、基线、目标值、红线及测量方式。边界建议用风险分级管理：

风险等级	定义	自治程度	人工介入	典型场景
L0	纯信息展示/检索	全自动	不需要	信息摘要、数据查询
L1	辅助决策，结果供人参考	输出建议	人确认后执行	客服推荐回复、初步分析
L2	先执行，人后复核	自动执行	事后抽查/可撤销	批量标注、文档初审
L3	强合规/高资损	人主导，Agent 辅助	每步审批	贷款审批、合同签署、资金操作

用"确定性×可逆性"确定自治程度的象限：

象限给出定位，分级表给出对应的关联。需注意 L1 出现在两个象限，卡的东西完全不同（质量 vs 权限）；L2 是用工程手段造出来的可逆性。

2.3 边界怎么划

方案	解决什么	不解决什么
A. 场景分级清单	统一"做/不做、谁确认"	拦不住运行时越权
B. 动作目录 + 策略执行点（PEP）	把"能不能做"从 Prompt 挪到调用前校验	不管知识对不对、流程顺不顺
C. SOP 编译成可执行契约	进入条件、槽位、守卫、停止条件可被机器执行	建设周期长，流程变更要发版

三档可以叠加，不必一次到位。先 A 避免做错场景，再对写操作上 B，最后把投诉、退款、政务办理等红线场景做成 C。

把“能不能做”从提示词挪到执行前：

03 让 Agent 真正理解业务知识

企业知识难点在于“查询时无法证明当前这条结论适用”。传统 RAG 存在口径冲突、条件知识切碎、时效版本混乱等问题。

3.1 传统 RAG 在企业里的失败形态

• 口径冲突：向量检索返回多条冲突内容，模型临时综合导致模棱两可。
• 条件知识被切碎：固定长度切块导致例外条款丢失。
• 时效与版本：过期内容持续进上下文。
• 权限后置过滤：被删片段仍可能影响 rerank 或有泄露风险。
• 静态知识与实时事实混用：交易数据编进知识库会过期。
• 检索命中≠答案可用：模型会补齐空白，高风险路径上比不回答更危险。

3.2 从 RAG 到知识编译：一个更好的范式

Andrej Karpathy 提出的 LLM-Wiki 模式主张“摄入时编译”（Ingest-time Compilation），即在资料到达时整理成结构化中间层，而非查询时临时拼凑。

企业落地需做三层适配：

第一层：从“个人 Wiki"到“企业知识层”，需满足来源管理、更新频率、权威性、多租户及合规要求。

维度	个人 LLM Wiki	企业业务语义层
来源管理	个人收藏的文章/笔记	产品手册、合规文件、SOP、工单等
权威性要求	自行判断	必须有明确的来源链接和生效日期
合规要求	无	知识变更需要审批、留痕、可追溯

第二层：三种知识操作（Ingest / Query / Lint）。摄入负责编译，取用负责按场景获取，体检负责定期找矛盾与过期。

3.2.1 Ingest：一次编译，而不是每次提问再拼

实践要点：

1. 原文只追加、不改写。原始文档是事实源，Wiki 是解释层。
2. 先立契约再写内容。页面类型、元数据、章节顺序要先定死。
3. 编译输出是补丁，不是整页重写。只更新被触及的结论。
4. 标明抽出与推断。推断占比高的不能当政策用。
5. 概念页要有门槛。避免每个词都变成孤页。
6. 日志可被机器读。便于审计和增量编译。
7. 机械活交给脚本，认知活交给模型。

3.2.2 Query：先消费已编译结论，而不是再去翻原文堆

查询要先分流，不要所有问题都走向量。模糊搜索前先读目录收敛范围。

实践要点：

1. 只索引编译结果，不索引原文堆。
2. 权限和时效在召回前过滤。
3. 多路召回，而不是只靠相似。结合元数据、关键词、向量及链接扩展。
4. 覆盖度是硬门槛。不满足当前条件的直接淘汰。
5. 未命中要诚实。禁止用通用常识补业务事实。
6. 实时事实不走 Wiki。库存、物流等走系统查询。
7. 对话成功一次，不能写成政策。需经审核编译后再发布。
8. 查询日志是体检的输入。

3.2.3 Lint：把健康度从“建库时合格”变成“持续合格”

Lint 检查包括结构完整性、链接有效性、新鲜度、冲突与口径等。严重级别应能挡住发布。

检查项	谁来做	典型信号	发现之后怎么处理
结构完整性	脚本，可进 CI	缺来源/缺生效时间	阻断发布
冲突与口径	模型建议 + 人裁决	两页对同一条件给出相反结论	暴露冲突，禁止自动选边
覆盖缺口	查询日志 + 规则	多会话重复问不到	补原文，再编译

实践要点：

1. 两道关：单页生成后检查字段，整库构建后全局对账。
2. Lint 是持续巡检，不是上线仪式。
3. 严重级别要能挡住发布。
4. 冲突只暴露，不默默综合。
5. 缺口要可晋升，需满足属于应覆盖领域且重复出现。
6. 健康度要能量化。

3.3 知识方案

从企业文档到业务语义，需跨过结构化、关联、可执行三道坎。不同场景适合不同方案：

场景类型	推荐模式	原因
快速变化的外部信息	RAG	不可能逐篇编译进 Wiki
稳定的内部知识	LLM Wiki	知识可编译、需要一致性、需要审计
半结构化数据分析	数据库查询 + LLM 解释	结构化查询比 RAG 精确得多

推荐节奏：

无论选哪种，切分要尊重结构、引用是一等公民、冲突要暴露、未命中要有策略、评测集要按场景构造。

3.4 知识缺口不是「这次没搜到」

可晋升的知识缺口需同时满足：属于企业应覆盖领域、当前 Release 未充分覆盖、Agent 最终没有引用有效证据、且在多个独立会话里重复出现。发现后的路径是：交互进入 Buffer→噪声过滤→主题归一→跨会话累积→达阈值进运营列表→补原始资料→走编译审核发布。

04 把经验变成能力

企业里真正有价值的知识是“怎么做”的经验，分布在 SOP、历史工单、老员工习惯及团队约定中。传统做法是将经验写进 Prompt，但面临失焦、难维护、无法复用等问题。

4.1 经验不只在文档里

• SOP：写得清楚但往往过时。
• 历史工单：真实案例记录，比 SOP 更细腻。
• 老员工的习惯：隐含大量未明说的规则。
• 团队约定：非正式讨论决定的处理方式。
• 错误教训：出错后的修正动作。

4.2 能力封装的分档

方案	解决什么	不擅长
A. 超长 Prompt / 少样本	最快让单一场景像样	多场景维护、灰度、回滚
B. 按意图加载的工作流	把步骤画出来，减少临场发明	开放域、用户中途改口
C. Skills + 渐进披露	能力多但上下文保持瘦	描述写不好会选错 Skill
D. 确定性骨架 + LLM 填槽与话术	高风险步骤不可漂移	覆盖不到的长尾

方案 C 的核心设计是渐进式披露：目录层只放 name+description，命中后才加载正文。工程上需做到一 Skill 一事、版本可回滚、独立评测。

经验要可发现、可版本、可按场景收紧工具，不能只活在某个人的脑子和一段不可回滚的文本里。

05 让任务持续推进

5.1 Agent 的本质是循环，不是一次生成

企业任务多为多步流程，Agent 的最小形态是循环：识别意图→核验→判断→检索→执行。循环里真正执行工具的是外围代码，不是模型。生产级 Agent 的控制权应在确定性代码上。

	一次生成	固定自动化	Agent 循环
下一步由谁决定	没有下一步	预先写死的节点	当前状态 + 规则/模型
中途新信息	无法消化	只能走已画的边	可以改计划再行动
适合	FAQ、摘要	分支清楚的标准流程	要判断、要选工具、路径不完全预设

5.2 Loop Engineering：设计循环，而不是把提示词写得更长

循环工程关心谁在什么时候启动下一圈、如何证明有效、什么条件下停止。一个能离开人盯着的循环，至少要有触发、目标、验收器、停止条件四件东西。

构件	它回答的问题	垂类业务里长什么样	缺了会怎样
触发	这一圈为什么现在开始	用户进线、工单创建、定时巡检	只能等人在对话框里按下回车
目标	怎样才算做完	“工单已派单且住客可见”	模型用流畅的结束语代替完成
验收器	谁来证明做完了	业务断言、规则引擎、人工确认	干活的给自己打分，分数会自己涨
停止条件	什么情况下必须停	达成目标、超步数、超时、费用上限	同一失败接口重试到重复扣款

Osmani 将循环分成四档：回合循环、目标循环、时间循环、主动循环。四档是嵌套关系，内循环解决“这一步怎么走”，外循环解决“这一步该不该走、走完算不算数”。

5.3 循环在生产里怎样失败

常见失败形态包括空转、目标漂移、假完成、副作用重放、窗口被撑爆、无人值守的自信。没有停止条件的循环和没有状态的多步一样危险。

评价维度	Demo 级	生产级
完成	看一次输出像不像	看完成断言是否被独立验证
错误处理	报错就人工介入	有界重试、降级、或升级为人工
任务连续性	每次从头开始	从权威状态续跑，已成功的写不重放
成本	不在乎	每圈有步数、超时和费用上限

5.4 垂类业务怎么选循环的形态

自由循环适合路径不完全预设场景；图编排/工作流适合分支、等待、人工卡点必须可审查场景。方案 D（确定性主链 + 局部循环）往往是最佳生产形态。

方案	解决什么痛点	不适合
A. 单轮检索生成	纯咨询、一次说清	办理、多系统、要写数据
B. 受控内循环	路径不完全预设，需要动态选工具	分支必须写死、强审批挂起
C. 把循环画成可审查的图	分支、等待、人工卡点要可测	强开放域、步骤很难预先画出
D. 确定性主链 + 局部循环	主路径要稳，局部要灵活	需要把所有步骤都交给模型时

06 让 Agent 接入系统

没有系统接入，Agent 只能解释世界；有了接入却没有控制面，它会改写世界。直连 API 会带来身份冒用、幂等缺失、部分失败等代价。

6.1 直连的五种代价

• 身份冒用（模型用服务账号打了用户不该打的接口）；
• 幂等缺失（超时重试造成重复创单、重复扣款）；
• 部分失败（工单创建成功、通知失败、库存未锁）；
• schema 与错误码不稳；
• 工具集过大（选错、漏传、越权概率上升）。

6.2 接入方案分档

方案	解决什么	风险/局限
A. 模型直连 API	最快做出"会查会写"	权限、幂等、审计裸奔
B. iPaaS/连接器编排	跨系统流转、触发、重试	对话状态与体验不在这层
C. MCP 标准协议	统一方式暴露工具与资源	协议不管业务级鉴权与配额
D. 工具网关（推荐主路径）	身份、schema、幂等、审计、熔断集中处理	要建设网关本身

一个形象的类比：MCP 是"USB-C 接口”，解决怎么连；工具网关解决能不能连。

方案 D 的最低配置包括：调用身份与用户身份绑定、按场景的工具白名单、JSON Schema 校验、幂等键、超时与熔断、结构化错误等。补偿策略要预先写清。

当 Agent 具备代码执行能力时，需要考虑额外的沙箱隔离。Dify 平台在 API 模式下的 Skills 运行在无网络访问的沙箱容器中，这是一种生产可用的安全策略。

形态	能做什么	不能做什么	治理复杂度
信息型 Agent	回答知识问题、生成文本摘要	执行任何写操作	低
辅助型 Agent	建议操作、生成待办、推荐路由	直接操作业务系统	中
执行型 Agent	创建工单、发起审批、更新数据	涉及资金的写操作	高

07 支持长任务与恢复

7.1 任务常常跨轮次

企业长任务常面临等待外部输入、需要人工审批、流程跨系统、定时触发及异常中断等情况。如果 Agent 只存在于一次对话的上下文窗口中，无法支撑这种时间跨度的业务。

中断类型	示例	持续时间	恢复难度
等待外部输入	等待客户上传补充材料	数小时到数天	中
需要人工审批	经理审批退款申请	几分钟到数小时	低
异常中断与恢复	系统崩溃、网络超时	不可预知	高

7.2 Context ≠ Memory ≠ State

概念	含义	存储周期	典型实现
Context（上下文）	当前推理窗口中的全部 token	单次推理周期	LLM 上下文窗口
Memory（记忆）	跨会话持久化的信息	天到月	向量库、结构化记忆存储
State（状态）	任务执行的当前进度	任务生命周期	检查点（Checkpoint）/ 事件溯源

7.3 支持断点续跑

生产级长任务系统需要两种恢复模式：检查点模式（Checkpoint-based）和事件溯源模式（Event Sourcing）。状态管理是业务连续性的工程基础。

• 检查点间隔是否合理？
• 中断后恢复时，Agent 是否向用户确认？
• 人工审批的中断是否支持持久化等待？
• 状态数据是否有备份？

08 让 Agent 可衡量、可治理、可进化

8.1 上线后的漂移与评测错位

上线不是终点。知识过期、工具变慢、模型升级改变工具选择等会导致漂移。评测错位则更隐蔽：用通用榜单替代场景评测，会放过错误承诺；只看最终回复不看轨迹，发现不了“选错工具但话圆回来”的情况。

8.2 分层指标

任务层	完成率、一次解决、转人工、时长
能力层	某场景步骤完成、错误分支、准确率
工具层	调用成功率、超时、幂等冲突
知识层	命中率、引用覆盖、过期、冲突检出
风险层	幻觉、越权、错误承诺、资损
体验与成本	满意度、接管、费用、延迟

与之对应的发布体系：离线黄金集回归、灰度、按版本回滚。

8.3 自进化

Agent 的自进化分两大分支：改脚手架（Prompt、Skill 等，更新快、可逆）与改模型权重（微调/强化，持久但慢）。对多数垂类业务，先把脚手架循环跑通就是全部答案。

自进化的难点是“判断修改有没有真的变好”。门禁必须硬：

门禁	作用	类比
有界编辑	每次只做小的增/删/改	学习率
留出验证集门控	候选必须严格优于当前版本才接受	验证集
拒绝缓冲	被拒的修改不丢弃，作为负反馈	经验回放
生成器/验证器隔离	改策略的和打分的不能是同一个	利益回避

• 轨迹先分级再优化；
• 任何自进化输出都是新版本或 PR，不原地覆盖；
• 评估器只读。

09 平台能不能直接套用

很多垂类业务的第一反应是：能不能用现成平台直接搭？答案是：可以，但有明确的能力边界。

能力维度	Dify 类	WorkBuddy 类	云厂商 AgentOps 类	纯框架
适合起点	知识问答、标准流程	企业办公协同	已深度使用对应云的平台团队	Agent 行为核心竞争力的团队
私有化/合规	社区版自托管门槛低	公有云/VPC/私有三种交付	深度绑定对应云	完全自主
长任务/断点续跑	弱	部分支持	各家在补	框架有 checkpointer，仍需自建恢复层
行业纵深	无预置，需自建	20+ 行业实践	行业方案随云生态	全部自建

10 抓住不变的东西

名词会过时，但企业反复出现的问题不会。真正成熟的生产级 Agent，是一套围绕业务闭环的能力栈。

企业里反复出现的问题	本文用过的技术名（会换）	换了名字之后仍要回答
目标打架、红线写在 Prompt 里	四象限、PEP、可执行规格	这次运行到底允许做什么，错了谁负责
口径冲突、过期条款被流畅复述	RAG、混合检索、Wiki	当前这条结论是否适用、能否指回某一版原文
打法只在老员工和工单里	Prompt、工作流、Skills、轨迹蒸馏	经验能否被发现、版本化、按场景收紧工具
动作散落各系统、模型会越权写	MCP、工具网关、幂等、补偿	提议与执行是否分开，失败能否收场
跨轮、跨时间、跨人工	Context/Memory/State、检查点	接着聊和接着做是不是两回事
上线后静默变差	分层 SLI、黄金集、灰度回滚	用什么证明还可靠，错了如何缩小半径

与其追每月一个的新名词，不如回到最根本的四个问题：

• 你的业务里，什么知识最值得被编译和沉淀？
• 你的团队里，什么经验最需要被封装成能力？
• 你的系统里，哪些边界是 Agent 永远不该跨越的？
• 你的治理体系里，什么指标真正衡量 Agent 的价值？

回答了这四个问题，就知道接下来该投入什么。名词可以明天再追，行动今天就要开始！

欢迎留言一起参与讨论~