上一章解决的是一个更大的判断：
为什么业务语义、业务规则、业务流程是第一性问题。这一章则继续把这件事拆细。
如果说上一章回答的是“Agent 为什么必须进入业务世界”，那么这一章回答的就是：
Agent 进入业务世界之后，到底要理解什么。一个成熟的业务型 Agent，至少要同时理解五层结构：
- 对象
- 状态
- 关系
- 例外
- 责任链
这五层不是并列名词，而是一个逐步变硬的业务骨架。 它们共同决定 Agent 是在“理解一句话”，还是在“理解一个真实运行中的业务系统”。
先看第一层，对象。
对象不是一个抽象概念，而是业务里的承载单元。
订单、退款单、工单、患者、合同、设备、告警、审批实例，这些都属于对象。
DDD 的参考资料把 Entity、Value Object、Aggregate 这些概念放在领域模型中心；本体建模与 OWL 又把“类、属性、实例、约束”做成形式化语义结构。
这些材料合在一起，会导出一个很重要的结论：
Agent 不能直接对“世界”做推理，
它必须先把世界切成可识别、可引用、可比较、可约束的对象。没有对象，系统就无法稳定回答下面这些问题：
- 它此刻处理的到底是哪一个业务实体
- 这个实体的身份如何确认
- 哪些字段只是属性，哪些字段会改变行为
- 哪些对象应被聚合看待，哪些必须拆开
研究对象中心学习的工作也在强调类似事情。 无论是 Slot Attention，还是 object-oriented dynamics 这样的方向，核心都不是“视觉技巧”，而是一个更普适的判断：
先把环境分解成对象，再去理解和预测，系统会更可泛化，也更可解释。这对 Agent 特别重要。 因为不做对象化，后面所有状态、关系、规则和责任都无从附着。
第二层，是状态。
对象不是静止的。 对象一旦进入业务流程，就一定带有生命周期。 订单有待支付、已支付、待发货、已签收；患者有初筛、复核、转诊；事件有检测、响应、恢复、复盘。
因此，Agent 理解对象，永远不可能只理解“它是什么”，还必须理解“它现在处于哪一阶段”。
经典状态机理论、Statecharts、SCXML、UML 状态机、PSSM 以及 IBM 的 business artifact / GSM 生命周期工作，都在说明同一件事：
状态不是标签，而是允许动作集合与后继路径的定义。也就是说，状态真正决定的是：
- 现在允许做什么
- 现在不允许做什么
- 什么事件会触发迁移
- 迁移后会打开哪些下一步
- 哪些历史状态会影响当前判断
如果 Agent 不理解状态，就会出现一种非常典型的业务错觉： 它以为自己在回答用户问题，实际上它在越过生命周期约束做决策。
例如用户说“帮我取消订单”，系统真正需要先看的不是语言本身，而是：
- 订单是否已支付
- 是否已出库
- 是否已发货
- 是否已签收
- 是否已经进入售后流程
同一句话，在不同状态下，对应的是完全不同的合法动作空间。
第三层，是关系。
现实业务从来不是单对象世界，而是对象网络。 ER 模型很早就说明，实体和关系都应该被单独建模；RDF、知识图谱和 SHACL 又进一步把“关系、全局标识、图约束、验证”做成正式表达。
这件事为什么重要？
因为很多业务判断不是看单个对象，而是看对象之间的依赖。
例如：
- 退款单依赖订单
- 订单依赖客户身份
- 审批实例依赖提交人、审批人、上级角色
- 告警依赖服务、资产、值班人、变更记录
- 病例依赖患者、检查结果、转诊单、责任医生
Agent 如果只看单个对象，很容易在局部上显得合理，在整体上却做错。
关系层至少包含三类东西：
- 归属关系：谁属于谁，谁依附谁
- 约束关系：谁限制谁，谁与谁互斥
- 身份关系：跨系统记录是否指向同一真实对象
record linkage 这一类研究特别能说明最后一条。 在真实企业里，不同系统经常没有天然统一主键。 CRM 里的客户、支付系统里的账户、客服系统里的会话主体，可能本质上是同一人，却被拆成不同记录。 如果 Agent 不能处理这种“跨源身份对齐”，它对关系的理解就会停留在单表语义里，无法进入真实业务网络。
第四层，是例外。
很多团队一开始都会把业务理解成“标准路径”。 但真正让 Agent 失控的，通常不是标准路径，而是例外路径。
例外包括但不限于：
- 信息缺失
- 状态冲突
- 超时
- 权限不足
- 审批挂起
- 跨系统不一致
- 高风险条件触发
- 用户诉求和系统状态矛盾
这也是为什么例外不能被看作“边角料”。 OpenAI 的 agent governance 材料、NIST 的 MANAGE 4.1、EU AI Act 的 human oversight 条款，以及 safely interruptible agents / off-switch game 这些工作，都在提醒一件事：
一个成熟 Agent，不是只会在理想路径里推进任务，
而是必须被设计成在异常路径里仍然可中断、可回退、可覆盖、可升级。换句话说，例外不是正常流程的噪声，而是系统韧性最真实的考点。
如果系统只能在一切顺利时工作，那它并没有真正理解业务。
第五层，是责任链。
责任链是最容易被忽略、却最能决定 Agent 能否落地的一层。 因为业务动作不只是“能不能做”，而是“该由谁做、谁批准、谁接管、谁留痕、谁复盘”。
企业平台的审批实现把这一点表现得非常清楚。
在 ServiceNow、Salesforce、Microsoft Power Platform、Google Cloud Application Integration 里，审批都不是抽象按钮，而是：
- 挂在某个具体对象或记录上
- 有明确的状态集合
- 有提交人、审批人、所有者、观察者等关系
- 有过期、拒绝、取消、跳过、恢复等例外分支
- 有审计轨迹和回写字段
这说明责任链的本质，不是“找一个人兜底”，而是把权力、权限、状态与审计做成同一条结构链。
一个 Agent 如果只知道“谁有权限”，还不够。 它还要知道：
- 当前责任人是谁
- 下一个责任人是谁
- 什么条件下必须升级
- 什么条件下必须暂停等待
- 什么情况下人工只能复核，什么情况下必须接管
因此，真正的责任链理解，至少是以下四件事的叠加：
- 权限归属
- 流程归属
- 风险归属
- 结果归属
把这五层放在一起，再回看很多业务错误，就会清楚得多。
例如用户说：
“我已经申请过退款了，但包裹昨天又到了，现在页面又显示退款审核中，我到底该怎么办？”
表面上，这是一句自然语言。 但对 Agent 来说，它其实同时触发了五层分析：
- 对象：订单、退款单、物流单、工单
- 状态：已签收、退款审核中、是否已生成逆向单
- 关系：退款单和物流状态是否矛盾，补偿权限是否与订单类型绑定
- 例外：这是标准退货路径，还是拒收转签收的异常路径
- 责任链：能否自动处理，还是必须转人工售后、财务或风控复核
如果 Agent 只做语言理解，它大概率会给出一段“听起来很贴心”的解释。 如果它真的理解这五层，它会知道自己首先面对的是一个状态冲突与责任升级问题。
高风险行业把这件事看得更明显。
在医疗场景里，SepsisWatch 这类系统的核心问题不是模型是否聪明，而是患者、护士、医生、告警、数据管道、界面这些对象和角色之间的关系是否清晰可见。 在手术机器人里，自主级别越高，人工监督责任越重；一旦环境变化超出边界，系统必须知道何时请求医生接管。 在运维与安全响应里，事件本身就是一个状态机，而领导层、响应人员、法务、资产 owner、第三方云服务商共同构成责任链。
这些案例共同说明：
对象、状态、关系、例外、责任链不是业务细节，
而是 Agent 在高责任环境里感知世界、决定动作、处理失败的最小结构。所以，这一章真正想留下的不是“五个名词”，而是一套更可执行的判断法。
看一个业务 Agent，先连续问五个问题：
第一，它到底在处理哪些对象，这些对象的身份与边界是否清楚。
第二，这些对象当前处于什么状态，状态转移是否被显式定义。
第三，这些对象之间有哪些关键关系，跨系统身份与依赖是否可追踪。
第四，标准路径之外最重要的例外是什么，系统是否有中断、回退、升级与人工覆盖机制。
第五，谁对当前动作负责，谁审批，谁接管，谁为结果留痕和复盘。
如果这五个问题回答不清，系统就很可能仍停留在“会说业务话”的阶段。 如果这五个问题回答得很清楚，Agent 才开始真正进入“会在业务系统中办事”的阶段。