很多系统在 demo 中表现不错，一进入真实业务就明显失真。
最常见的原因，不是模型绝对能力不够，而是系统没有真正进入业务世界。
所谓“进入业务世界”，不是让模型学会几句行业黑话，而是让它明确三件事：
- 它正在处理的对象到底是什么
- 这些对象受哪些规则约束
- 它此刻位于哪一段业务流程中
如果这三件事不清楚，Agent 就算会搜索、会调用工具、会多轮推理，也仍然只是悬浮在业务表面。
所以，本章想给出一个很硬的判断：
业务语义、业务规则、业务流程，不是 Agent 的外围适配层，
而是 Agent 得以成立的第一性结构。为什么说它们是第一性问题？ 因为它们分别决定了 Agent 的三种根本能力：
- 业务语义决定 Agent 到底看见了什么世界
- 业务规则决定 Agent 到底被允许做什么判断
- 业务流程决定 Agent 到底应该在什么时候做哪一步
这三层一旦缺失，系统就会立刻出现一种典型症状：
- 词汇上看起来懂业务
- 推理上看起来很聪明
- 真到推进业务时却不断犯低级错
这不是偶然，而是结构性后果。
先看第一层，业务语义。
Martin Fowler 在讲 Bounded Context 时强调，大领域不可能维持单一统一模型；同一个现实对象在不同上下文里可以有不同含义。
Microsoft 在领域分析文档里也给出了同样的工程判断：不应为整个系统强行使用一个统一模型，而应先划清业务边界，再谈领域对象和行为。
这件事对 Agent 特别关键。
因为 Agent 的很多错误，并不是“不会回答”，而是“在错误的上下文里回答得很自信”。
例如在一个企业服务系统里，account 这个词在身份系统、结算系统、客服系统里可能分别指：
- 一个身份主体
- 一个资金账户
- 一个客户服务视角下的用户实体
如果上下文边界没有先划清，Agent 看到的就不是一个稳定对象，而是一团模糊语义。 这时候它再强，也只能在模糊对象上做模糊判断。
因此，业务语义的核心从来不在词，而在结构。 它至少包括：
- 对象定义
- 对象边界
- 对象关系
- 状态含义
- 上下文中的统一语言
没有这一层，所谓“理解业务”其实只是理解了话术。
再看第二层，业务规则。
业务规则的意义，不是让 Agent “听起来更专业”，而是给判断设置边界。
Microsoft 的 Tactical DDD 文档明确强调，business rules、validation、state transitions 应当进入 entity、aggregate 和 domain service，而不是漂浮在外层应用逻辑里。
OMG 的 DMN 标准则进一步说明，业务决策和业务规则本身就应该被显式建模，而不是隐含在自然语言描述里。
这意味着，对 Agent 来说，业务规则至少要回答四个问题：
- 哪些动作在当前状态下允许发生
- 哪些条件一旦满足必须阻断自动推进
- 哪些例外可以自动兜底，哪些必须升级人工
- 哪些不变量无论如何都不能被破坏
如果规则不被单独建模，而只是散落在 prompt、代码注释、操作手册和人脑经验里，Agent 的表现就会极不稳定。 因为它遇到的不是“是否会推理”的问题，而是“推理依据到底有没有被结构化地给出来”的问题。
很多团队在这里会踩同一个坑。
他们以为只要把政策文档、FAQ、SOP 喂给模型，模型自然会学会业务判断。 但真实情况是：
- 文档也许描述了规则
- 模型也许读懂了规则
- 系统却仍然没有把规则做成可执行边界
一旦进入例外场景，这种缺口就会暴露出来。
例如售后场景里，系统不能只知道“原则上可退款”。 它必须知道：
- 当前订单是否已签收
- 当前退款是否已发起
- 是否存在补偿与退款互斥规则
- 特定会员等级是否拥有额外权限
- 哪些异常履约状态必须走人工复核
这些都不是“更会说”的问题，而是“规则是否进入系统”的问题。
第三层，是业务流程。
流程不是装饰，它决定时间顺序、责任顺序和风险顺序。
BPMN 把业务流程当作可以被业务方定义、管理并映射到执行组件的结构对象；van der Aalst 的 BPM 综述则把过程运行中的 control flow、data/rules、resources/organization 一起看作系统核心。
这说明，在成熟的业务系统里，流程从来不是“先有模型，再补一个图”，而是系统骨架的一部分。
这件事放到 Agent 上，意义非常直接。
Agent 不是只要知道“该做什么”就够了，它还必须知道：
- 现在处于哪个环节
- 下一步该推进到哪里
- 哪一步可以并行
- 哪一步必须等待
- 哪一步需要审批
- 哪一步失败后必须回滚或中止
Microsoft 在业务流程建模和状态框架文档中，把状态、状态原因、状态转移、源状态、目标状态都做成显式对象。 ServiceNow 的审批动作文档也明确把审批放在具体 record 上处理，并要求定义 approval、rejection、cancellation 等分支。 这都在说明一件事：
真正的业务流程不是一串自然语言步骤，
而是带状态转移、条件分支、责任归属和中断机制的执行结构。如果 Agent 不理解这一层，它就无法真正“推进流程”，只能在流程边上说话。
为什么这三层会被称为第一性问题，而不是“业务细节”？ 因为 Agent 的五个基本环节，其实都依赖它们：
- 观察要靠业务语义才能看懂对象与状态
- 决策要靠业务规则才能知道边界与优先级
- 动作要靠业务流程才能知道时机、顺序和责任链
- 反馈要靠业务状态才能知道推进是否成功
- 停止条件也要靠业务定义才能知道何时算完成
换句话说，如果没有业务语义、规则和流程，Agent 连“自己此刻在干什么”都很难稳定回答。
这也是为什么 OpenAI、Anthropic、Google、Salesforce、ServiceNow 这些平台在公开材料里越来越少把 Agent 描述成“一个聪明模型”，而越来越多把重点放在：
- structured state
- guardrails
- human approval
- workflow nodes
- business logic
- systems of record
- compliance requirements
OpenAI 在 agent safety 和 node reference 里把 if/else、while、guardrails、human approval、set state 做成一等原语，实际上已经在告诉开发者：
Agent 不是一个漂浮的对话循环，而是一个受业务结构约束的运行系统。
Anthropic 的立场也非常一致。 它一方面强调 workflow 对于步骤清晰、要求稳定的任务更合适，另一方面又强调 eval 的价值在于逼团队把成功标准和边界情形写清楚。 这背后的意思很清楚：
没有明确的业务边界和异常定义，就没有可靠的 Agent。企业平台给出的证据更直接。
Salesforce 在 Agentforce 2dx 的公开材料里强调把 agent 嵌入现有 business logic、Flow 和 Apex。
Google 的 Vertex AI Agent Builder 明确写到 agent 要连接企业系统与 existing workflows，并遵循 business rules and compliance requirements。
ServiceNow 则把审批、工作流、record、数据底座和治理框架放在同一平台叙事里。
这些平台并不是“保守”，而是在承认企业现实：
- Agent 不能脱离 system of record 行动
- Agent 不能跳过审批和权限结构行动
- Agent 不能绕开流程责任链行动
只要进入真实业务，模型自由度就必须让位给业务确定性。
高风险行业的论文和案例又把这个判断推得更彻底。
在临床决策支持场景里，研究者关心的不是模型是否像医生那样对话，而是它是否能在分诊、转诊、诊断这些序列化流程里稳定工作。 在 FAIR-AI 框架里，问题更进一步变成：什么级别的风险要走什么级别的治理、审批和持续监控。 在化学机器人实验里，一个很小的异常如果没有被流程化识别和处理，就可能中断整个实验并引入安全风险。
这些场景共同说明：
一旦任务进入高责任、高风险、高成本的业务世界，
Agent 的首要问题就不再是“能不能想”，
而是“是否被放进了正确的语义、规则和流程结构里”。因此，本章真正想强调的是一种次序。
很多团队的次序是：
- 先选模型
- 再接工具
- 再补 prompt
- 最后才想业务规则和流程
这通常会导致系统越来越复杂，但越来越不稳。
更合理的次序应该是：
- 先划清 bounded context
- 再明确业务对象、状态与关系
- 再抽出规则、不变量、审批和升级条件
- 再把流程节点、状态转移和责任链定义清楚
- 最后才决定哪些局部步骤值得交给 Agent 自治
只有在这个次序里，Agent 才不是“替代业务结构”，而是“运行在业务结构之上”。
如果把这件事压缩成一句最值得记住的话，可以写成：
业务语义定义世界，业务规则定义边界，业务流程定义时间；
这三者先成立，Agent 才有可能稳定成立。也正因为如此，一个成熟的业务型 Agent，首先应该被问的不是“模型有多强”，而是下面这些问题：
- 它服务于哪个 bounded context
- 它处理的核心对象和状态是什么
- 它遵守哪些明确业务规则与不变量
- 它所在流程的阶段、分支和停止条件是什么
- 它的审批、升级、留痕和人工接管点在哪里
如果这些问题回答不清，系统大概率只是一个会说业务语言的模型外壳。 如果这些问题回答得很清楚，即便模型不追求最大自治，它也更有可能成为一个真正可用、可管、可扩展的业务 Agent。