搭建业务 Agent 前，先定义「决策契约」

最近三个月，和客户聊得最多的，就是怎么搭建业务 Agent，也就是数字人。

我发现大家的思路都很像：先盘数据，给 Agent 喂上下文。CRM、订单、合同、知识库、聊天记录、经营报表，能接的都接进来。

这条路径听起来没问题，我一开始也觉得顺理成章，业务 Agent 也确实能搭起来。它会查资料、做总结、提示风险。最后却很容易回到传统问答机器人的状态：什么都知道一点，却不对任何结果负责。

比如，它不会直接告诉你：「某个客户出现了流失风险，现在应该采用什么策略。」

怎样才能让 Agent 像一位资深业务专家那样思考、判断？看到 Data-first 和 Decision-first 这两个方向后，我似乎有了一个新的答案。

Data-first 和 Decision-first 的区别是什么

决策管理领域很早就在讨论这个问题。Decision Management Manifesto 提出，应该先把业务决策建模，再考虑规则和分析怎么支持它。OMG 的 DMN 标准则把决策、子决策、输入数据和业务知识之间的依赖关系画出来，方便业务人员、分析师和开发者一起讨论。

Data-first 的常见链路是：

已有数据 → 指标和分析 → 洞察 → 人理解 → 人做决定 → 人执行

Decision-first 把链路倒过来：

业务目标 → 要做的决定 → 可选动作 → 所需事实和规则
→ Agent 判断 → 人工确认或自动执行 → 结果写回

总结一句话就是，Data-first 先问我们有什么数据。Decision-first 先问业务里有什么决定需要持续做好，然后才去找支撑这个决定的数据、规则和动作。

顺序换一下，最后做出来的东西也会很不一样。

正向之路：Data-first，最后 Agent 只是分析助手

往往我们习惯先走 Data-first 这条路，也就是用数据范围定义 Agent 的职责。接入销售数据，就叫销售 Agent；接入项目数据，就叫项目 Agent；如果把几套系统都接进来，名字可能再大一点，叫企业数字人。

但能读什么，和应该负责什么，是两回事。

一个 Agent 即使读完所有客户资料，也未必知道该先挽回哪位客户。它可以识别订单延期，却不清楚该找谁处理、多久需要升级。它也能生成一份很完整的经营分析，但当利润、库存和客户体验发生冲突时，它缺少可执行的取舍规则。

于是我们会看到一种很常见的结果：Agent 告诉你「这个客户存在风险，建议及时跟进」。这句话当然没错，但缺少了真正有价值的部分：风险多高才需要行动？谁来行动？用什么方式？可以给多少商务条件？几天没有进展要不要升级？

这些判断如果还藏在少数 TOP 销售、主管或老板脑子里，Agent 接再多数据也只是分析助手。

反向而行：Decision-first，换一个起点

假设我们要做一个客户续约 Agent。

Data-first 的做法，通常是先接入 CRM、沟通记录、合同、回款、工单和产品使用等数据。Agent 据此生成客户摘要、风险评分和跟进建议。做到这一步，演示往往已经很好看了。

Decision-first 不急着接数据，而是先定义这项工作中反复出现的关键决策：

当客户进入续约前 45 天且出现风险信号时，我们该继续常规培育、安排高层介入、给出商务方案、升级为经营风险，还是暂不行动？

决策命题一旦明确，后面的需求就会变得具体。

比如：什么情况下触发判断？除了续约日期，可能还包括重大投诉、使用量突然下降或逾期回款。Agent 有哪些可选动作？哪些条件会改变选择？折扣底线是多少？涉及合同承诺时，谁来确认？采取动作后，记录写回哪里？最终评价看续约率、续约周期，还是毛利变化？

很多客户数据其实并不需要。只有那些会改变这项决定的事实，才值得进入 Agent 的上下文。相应地，工具的用途也更明确：查事实、分任务、起草沟通内容、发起审批、写回结果。

业务上下文不能靠堆资料，先写「决策契约」

现在聊搭建 Agent，大家往往很在意给它足够多的上下文。常见做法是不断往里加：多接一个系统、多放一批文档、再做一套知识库。仿佛资料堆得足够多，Agent 自然就会知道该怎么做。

我觉得这里很容易混淆两件事：知道什么，和真正需要什么。

• Data-first 回答的是：Agent 知道多少。
• Decision-first 回答的是：眼前这项决定需要知道什么。

如果把业务 Agent 当成一个数字岗位，我会在写 Prompt、配工作流之前，先把下面这张表填完。

我把它定义为「决策契约」。它更像一份能运行的岗位说明书，比一段写得很长的 Prompt 管用。

举两个例子，会更容易理解。

电商：这笔售后单该怎么处理

用户发来一张商品破损照片：订单金额 168 元，物流显示昨天已签收。Data-first 的 Agent 可以将订单、物流和历史沟通整理成一份摘要。但客服真正要处理的是一道选择题：直接退款、补发、请用户补充凭证、拒绝申请，还是转人工？

如果给这个售后 Agent 写决策契约，我会这样写：

写到这里，Agent 需要接什么数据已经很清楚了。它不需要翻完整个会员画像，只要拿到会改变这次售后决定的事实。

制造：订单出现交期风险后怎么办

再看一个制造现场：某张订单将在 48 小时后出货，关键物料预计晚到 10 小时，原定产线又临时停机。分析型 Agent 很容易给出「存在延期风险，请及时关注」的结论。但计划员面对的是一组更具体的选择：调整排产、切换产线、安排加班、拆单先发、临时外协，还是尽快与客户重谈交期？

这份决策契约可以这样写：

这个例子里，数据更多，参与的人也更多。决策契约的价值在于先把冲突摊在桌面上：保交期要多花多少钱，谁有权改排产，谁能对客户改口。Agent 可以算方案、追进度、发起确认，但不能在大家不知情的情况下替组织做掉这些取舍。

OpenAI 的 Agent 实践指南把数据工具和行动工具分开讨论，也建议对高风险动作设置人工介入。这个区分很务实：一旦系统开始发消息、改记录、分任务或做审批，权限边界和接管机制就不能留到最后再补。

这也是我现在理解「业务数字人」的关键点：先把服务对象、目标、职责范围、行动权限、升级关系和工作记录定下来。如果缺少这些东西，它更像一个问答机器人的界面。

容易踩的坑：Decision-first 也会走偏

从决策出发，并不意味着什么都要交给 Agent 拍板。恰恰相反，先对决策建模的一个好处，就是可以提前定义权限边界，让它真正稳定地运行。

• 刚上线时，Agent 可以只负责整理事实。
• 运行稳定后，再让它提出建议，由人确认。
• 低风险、可逆的动作跑顺了，才考虑在阈值内自动执行。
• 退款、合同承诺、价格调整这类影响重大的动作，长期保留人工确认。

定义业务 Agent 的作用，不要盲目把自动化程度当作核心指标。真正需要考虑的是：一旦 Agent 判断错了，损失有多大？动作能不能撤回？过程有没有记录？谁可以及时接手？

更需要关注的是，怎样把那些经常重复、却分散在个人经验中的判断，变得可管理、可修改。

Data-first 该放在哪

这并不意味着要把 Data-first 推到对立面。很多时候，我们一开始确实不知道问题在哪里：探索一批数据、寻找异常、做一次战略分析，或先摸清企业有哪些数据资产，这些工作都适合从数据出发。

但当一个场景准备进入生产，要求 Agent 反复运行、调用工具、改变业务状态，并对结果进行评估时，就该切换到 Decision-first，也就是决策视角。因此，我更倾向于这样划分：

探索阶段用 Data-first 找问题
生产阶段用 Decision-first 接工作

数据基础设施可以从 Data-first 建设
具体业务 Agent 应围绕 Decision-first 设计

两条路不冲突。Data-first 负责打开可能性，Decision-first 负责把其中一项可能性做成组织可以长期使用的业务 Agent。

在开始搭业务 Agent 时，先列「决策清单」

很多 Agent 项目的需求文档，第一页往往是能力清单：查数据、写报告、发消息、建任务、调用系统。现在我会把这一页先放到后面，把更重要的事提前，先列清业务里需要做出的决定：

• 哪些决定高频发生，却要人反复找资料？
• 哪些决定有明确的负责人和结果？哪些一旦拖延就会带来损失？
• 哪些风险较低，适合先做「Agent 给建议，人来确认」？
• 哪些事情做完之后，能在系统里看到结果？

选中一项写决策契约：只接入最少且必要的数据，配置关键规则和工具。

第一版不必追求自动化，先做到「给出建议，由人确认」即可，但每次判断都要写回依据、动作与结果。运行一段时间后，再复盘哪些规则有效、哪些例外此前没有覆盖。

这样的第一版通常不大，却更容易验证。你能看见它究竟接走了哪段工作，也能说清它做得好不好。

随着运行的积累，Agent 会越来越贴近业务，连接系统的工具也会逐步标准化。企业最终留下来的差异，往往正是这些看似不起眼的细节：一项决定需要看哪些事实，遇到哪些例外必须暂停，谁有权批准，以及过去的选择带来了什么结果。

所以，下次搭建业务 Agent：

• 先不问「我们能给 Agent 接多少数据」。
• 先问「这条业务链里，我们希望它把哪个决定做得更好」。