垂直业务 Agent

一句话理解：垂直业务 Agent 用“窄而深”换可靠性——Job 窄到可以定义结果、工具深到直连业务系统、关键路径交给确定性逻辑、价值直接按解决量或处理量计算；这是目前商业价值最清晰的 Agent 形态。

通用 Agent 让人惊艳，垂直 Agent 让人付费。原因很简单：客服工单是否解决、线索是否被跟进、发票是否匹配、告警是否被处置——这些结果都能被业务系统确认，价值也能被直接换算成钱。

本课是产品拆解模块的最后一课，也是对整个课程的回收：我们先看垂直 Agent 的共同结构，再拆解两个真实产品的关键设计——客服领域的 Intercom Fin 与 CRM 平台 Salesforce Agentforce，最后用同一框架对比财务与运维 Agent 的设计示例。产品信息以官方页面为准，查询时间为 2026 年 9 月。

垂直 Agent 的共同结构

与通用 Agent 相比，垂直 Agent 的差异不在模型，而在四个“深”：知识深、集成深、规则深、指标深。

案例一：客服 Agent——Intercom Fin

Fin 是 Intercom 的客服 AI Agent。按八个问题看它的关键设计：

问题	Fin 的做法（依据官方帮助文档与定价页）
Job	解决客户的服务咨询，并可以分诊、与人工团队协作
工具	通过 Data connectors 连接外部系统，为客户提供个性化回答并代客户完成复杂任务
上下文	帮助中心文章、内部支持内容、PDF 与网页等知识来源
执行	部署在邮件、语音、在线聊天、社交等多个渠道
下一步	复杂问题用 Procedures 处理：以文档式编辑器编写步骤，并可在步骤中加入代码与 Data connectors；官方称它在 Fin Tasks 基础上做得更简单、更聪明
验证	用 Simulations 在真实场景中测试 Fin 的表现，覆盖从简单流程到棘手边界案例
人确认	可以配置何时、如何分诊或转交人工团队；官方说明当转人工对客户最安全时，Fin 总会自动转交
恢复	转人工兜底；按结果计费倒逼对解决质量负责

把表中的组件连起来，就是 Fin 的整体架构：

最值得产品经理学习的是它的 定价与结果定义。官方定价页显示 Fin 按每个 outcome 0.99 美元计费，outcome 的判定包括：客户确认问题已解决、Fin 回答后客户不再寻求帮助、或 Fin 完成一个 Procedure 流程（含转人工），且同一对话只收费一次。

这说明两件事：第一，客服领域的“结果”足够清晰，可以支撑按结果定价（参见「商业化与 ROI」）；第二，买方必须仔细阅读结果的定义——“客户不再寻求帮助”与“客户问题真的被解决”并不完全等价，需要用抽样复核来校准。

另一个值得学习的是 Procedures 的定位：它不是把客服 SOP 写死成流程树，也不是完全交给模型自由发挥，而是让业务人员用接近文档的方式写步骤，在关键步骤里嵌入代码与系统连接。这正是「步骤归类」中“Reasoning + Skill + Tool + Workflow 混合”的产品化形态。

案例二：确定性分级——Salesforce Agentforce

Salesforce 在官方的 Agentforce 可靠性指南中，把“如何让 Agent 行为可靠”总结为一组 确定性等级，从最灵活到最确定依次是：

等级	手段	含义
1	无指令的 Subagent 与 Prompt 动作	依赖模型的动态理解，自主性最高
2	Agent 指令	用规则与护栏明确指导
3	数据接地	用 RAG 提高准确性
4	Agent 变量	管理状态，保持上下文与个性化，并作为条件过滤
5	确定性动作	用 Flow、Apex 与 API 执行固定序列
6	Agent Script	为关键流程硬编码推理逻辑，把 LLM 的对话能力“夹”在不可变的确定性逻辑之间

指南中还提到一个术语变化：自 2026 年 4 月起，Agentforce 中的 Topics 更名为 Subagents，Topic Selector 更名为 Agent Router。

这张表对产品经理的价值在于提供了一种 沟通语言：评审时不再争论“要不要让 AI 自主决定”，而是逐个流程讨论“这一步需要几级确定性”。官方指南的核心观点是按需配置确定性——施加恰好足够保证安全的控制，同时不牺牲对话的灵活性。退款、改价、合同条款这类步骤放在 5–6 级；产品咨询、需求澄清放在 1–3 级。

把六个等级按确定性排开，并标出两类步骤的典型位置：

财务与运维：用同一框架看设计示例

以下两列是按本课程方法给出的 设计示例，不对应任何特定商业产品：

问题	财务：应付账款异常 Agent	运维：线上告警处置 Agent
Job	发票与采购订单、收货单三单不匹配时，定位原因并推进付款或退回	线上告警触发时，定位根因并执行预案或升级值班
工具	读 ERP 采购订单、收货记录、供应商主数据；写入“待补资料”状态；创建审批单	读监控指标、日志、变更记录、服务依赖；执行预案内的重启与扩容；创建变更审批单
上下文	付款政策、容差规则、供应商历史异常	故障处理手册（Runbook）、服务依赖关系、历史故障复盘
执行	API 直连 ERP；无 API 的老系统用受限的界面自动化	API 与内部运维工具服务；凭据由 Harness 注入
下一步	Agent 判断差异类型（数量、单价、税率、重复发票），规则引擎判断是否在容差内	Agent 判断故障类型（发布引入、容量不足、依赖故障、配置错误），程序校验动作是否在预案白名单内
验证	写入后读回状态；金额差异由程序重新计算	执行后读回指标；确认告警是否恢复
人确认	任何付款、供应商银行信息变更必须审批，禁止自动执行	回滚发布、修改生产配置、删除数据必须审批
恢复	数据矛盾时停止并升级；重复发票标记冻结	部分结论交给值班工程师；非幂等动作禁止重试
核心指标	自动匹配率、异常处理时长、误付款为 0	诊断准确率、人工介入率、平均恢复时长、越权动作为 0

两列放在一起会发现：不同行业的垂直 Agent，结构几乎一样。变化的只是工具、规则和指标；不变的是“窄 Job + 深集成 + 确定性骨架 + 结果指标”。这也是为什么学会拆解一个垂直 Agent，就能快速迁移到下一个行业。

可借鉴的设计决策

设计决策	来源	迁移方法
结果可定义，才能按结果定价	Fin 的 outcome 定义与计费	先写清“结果”的判定口径与抽样复核方式，再谈定价
让业务人员写流程	Fin Procedures 的文档式编辑	Skill 与流程用业务人员能读写的形式维护，工程师负责嵌入工具与校验
上线前做场景模拟	Fin Simulations	用历史工单与边界案例建立模拟测试，每次变更后重跑
转人工是一等公民	Fin 在最安全时总是转人工	升级路径与自动处理路径同样精心设计（参见「什么时候停下来找人」）
确定性按步骤分级	Agentforce 的确定性等级与 Agent Script	在 PRD 中为每个关键步骤标注确定性等级
高风险动作不交给模型	财务与运维示例	付款、改价、改主数据、改生产配置一律走程序校验与审批

常见误区

• “垂直 Agent 技术含量低，只是接了几个接口。” 真正的难点在于把行业规则、例外和审批嵌入系统，这恰恰是最难复制的壁垒。
• “解决率高就说明 Agent 好。” 解决率的口径可能很宽松。必须同时看转人工质量、客户满意度与抽样复核的真实解决率。
• “确定性越高越好。” 全部写死就退化成传统自动化，失去处理长尾问题的能力。确定性应该按步骤的风险来分配。

设计要点

• 用一句话写出 Job 的“结果”，并确保它能被业务系统确认。
• 列出每个关键步骤的确定性等级，高风险步骤放在程序与审批中。
• 把领域规则维护在业务人员可以编辑、工程师可以测试的载体中。
• 建立基于历史案例的模拟测试，并作为上线门槛。
• 把转人工设计成完整的交接，而不是失败时的兜底提示。

练习

选一个你熟悉的行业（例如电商售后、HR 入职、IT 服务台），用 60 分钟：

1. 仿照本文的表格，用八个问题设计一个垂直 Agent。
2. 列出它的 5 个关键步骤，为每个步骤标注确定性等级（1–6）并说明理由。
3. 写出它的“结果”定义，以及你会如何抽样复核这个结果是否真实。

延伸阅读

• Fin AI Agent explained（Intercom）：知识来源、Procedures、Data connectors、Simulations 与转人工。
• Intercom Pricing（Intercom）：Fin 按结果计费与 outcome 的定义。
• Agentforce Guide to Achieving Reliable Agent Behavior（Salesforce）：确定性等级与 Agent Script。

下一步

至此，你已经用同一套八个问题拆解了 Coding、通用、企业平台、个人常驻与垂直业务五类 Agent。回到「Agent 产品思维框架」，用它为你自己的场景完成一份「Agent PRD」——这就是整个课程的毕业作业。