做 Agent 时，最常见的错误之一，是从模型能力开始思考。
团队会先讨论：
- 用哪个模型
- 上不上推理模型
- 要不要加工具
- 要不要做多 Agent
这些当然都重要。 但如果顺序反了，系统很容易做成一个“技术上很热闹、业务上很空心”的东西。
从落地视角看，真正更稳的起点通常不是模型，而是业务。
因为 Agent 从来不是为了证明模型有多强而存在的。 它存在的理由只有一个：
在某个真实业务环境里，更有效地完成任务、推进流程、处理例外并交付结果。一旦这样看，很多事情就会清楚。
一个 Agent 的真正质量，不取决于它说得多像人，而取决于它是否能在业务世界里做出有效、合规、可持续的行动。
所以，从业务视角理解 Agent，首先不是看 prompt，而是看这八类东西：
- 业务对象
- 业务状态
- 业务关系
- 业务流程
- 业务规则
- 业务指标
- 业务例外
- 业务责任链
如果这些层没有进入系统，Agent 再聪明，也常常只是一个“会说行业黑话的模型”。
这也是为什么“业务适配”必须被单独拿出来讲。 它不是锦上添花的行业包装，而是决定 Agent 是否真的进入现实世界的那层结构。
为什么这样说？ 因为今天来自工程、研究、平台和行业案例的证据，正在持续收敛到同一个结论：
Agent 只有嵌入业务语义和业务流程，才会从模型能力变成业务能力。第一条证据，来自 DDD 与领域建模。
无论是 Eric Evans 的 DDD 传统，Martin Fowler 对 ubiquitous language、bounded context 的持续解释，还是 Microsoft 在微服务与领域分析文档中的工程化落地，都在强调同一件事：
- 系统边界应该围绕业务能力而不是技术模块划分
- 业务语言必须和模型、规则、责任、边界绑定
- 不同 bounded context 有不同的对象、状态、约束和行为
这对 Agent 的启发非常直接。 因为 Agent 如果要在业务里做判断，它就不能只会说“像业务的话”，而必须进入那个 bounded context 真正的语义结构。
例如，在零售里“订单已支付但未履约”和“订单已取消但退款处理中”听起来都像订单状态。 但对客服 Agent、风控 Agent、仓配 Agent 来说，它们意味着完全不同的下一步动作、权限和责任。
也就是说，业务理解首先不是语言理解，而是状态理解。
第二条证据，来自官方评测方法。
OpenAI 的 eval best practices 与企业 eval 文章一再强调，真实系统的评测必须由技术人员和领域专家共同定义，并且要覆盖真实边界样本、稀有高代价样本以及业务关心的失败模式。
这个建议非常关键，因为它把“好不好”重新绑定到了业务世界，而不是模型世界。
如果没有领域专家参与，团队往往只能评估：
- 回答是否流畅
- 格式是否正确
- 工具有没有调用成功
但这些都不足以回答业务真正关心的问题：
- 这个决策是否符合业务规则
- 这个动作是否真的推动了流程
- 这个例外处理是否可接受
- 这个系统会不会在关键边界上犯大错
OpenAI 在 2025 年的企业 eval 方法里甚至把这件事说得很直白： 如果你不能定义业务里“什么叫好”，你就很难把系统做对。
第三条证据，来自企业平台的共识。
无论是 Salesforce 的 Agentforce，还是 ServiceNow 的 AI Agents，它们几乎都没有把 Agent 描述成一个孤立的对话模型。 它们强调的都是：
- trusted business context
- systems of record
- workflow orchestration
- permissions and controls
- real-time data foundation
这意味着平台厂商已经默认一个前提：
Agent 的价值，不来自“有一个会思考的模型”，
而来自“这个模型能否接入可信业务上下文，并在受控流程里行动”。Salesforce 反复强调 business context、metadata、Flow、MuleSoft、permissions。 ServiceNow 反复强调 single architecture、single data model、Workflow Data Fabric、受治理的企业工作流。
这些平台的共同点不是都喜欢讲故事，而是都在回答同一个现实问题：
如果没有业务数据、业务权限、业务流程、业务责任链，Agent 根本无从落地。
第四条证据，来自高风险行业案例。
在医学、科研、化学等高风险或高专业度场景，大家对 Agent 的关注点从来都不是“像不像专家对话”，而是：
- 是否遵守专业流程
- 是否在正确节点调用正确工具
- 是否保留了人工监督或中断机制
- 是否能在错误代价很高的环境中维持过程连续性
Nature 的 A-Lab 强调的是 autonomy embedded in laboratory workflow。 npj Digital Medicine 的 agentic clinical workflow 研究强调的是专家驱动优化、确定性参数设置、流程可校准与安全部署。 MedChain 这类临床 sequential benchmarking 工作更进一步指出，真正难的不是医学问答，而是把 Agent 放进真实序列化临床流程以后，它是否还能稳定做对每一步。
这些工作都在说明：
当任务进入专业业务流程时，Agent 的核心问题就不再是“会不会答”，
而是“是否理解流程、状态、责任与风险”。第五条证据，来自治理与风险管理。
NIST 的 AI RMF 一直强调 context-specific governance，也就是风险评估不能脱离具体组织情境、具体业务场景和具体后果结构。
这对 Agent 特别重要。 因为 Agent 不是只输出一个建议，它常常会读取系统、触发动作、改变状态、影响流程。 一旦进入这类系统，风险就天然具有业务依赖性。
同样一个模型错误：
- 在营销文案场景，可能只是文风偏差
- 在医疗分诊场景，可能是患者风险分层错误
- 在理赔审核场景，可能是赔付责任误判
- 在 IT 运维场景，可能是错误执行变更
所以，风险不是抽象属于“AI”，而是具体属于“AI 在什么业务里、以什么权限、对什么对象、造成什么后果”。
第六条证据，来自组织与变革现实。
OpenAI 在面向企业的材料里已经明确提出，真正限制 AI 价值释放的，往往不是模型智力，而是 workflow redesign、system integration、leadership alignment 和 adoption。
这句话非常值得反复看。 它意味着企业 Agent 成败的瓶颈，很多时候根本不在模型层，而在组织与业务层：
- 流程有没有重构
- 权限有没有打通
- 责任有没有明确
- 一线团队是否愿意采用
- 系统输出是否接入现有 KPI
如果这些问题不解决，Agent 可能看起来很先进，但永远停留在 PoC。
第七条证据，来自反例。
几乎所有企业在第一阶段都会做出一种“会说业务话”的模型。 它能说：
- 我理解您的问题
- 我来帮您查看订单状态
- 根据公司政策，建议如下
但上线以后很快就会暴露出几个致命空洞：
- 它不知道当前服务的是哪个业务对象
- 它不知道这个对象当前处于什么业务状态
- 它不知道例外路径是否被允许
- 它不知道何时必须升级人工
- 它不知道系统目标到底是效率、满意度、风险控制还是合规优先
这些问题不是 prompt 再润色几轮就能解决的。 它们本质上是业务建模缺失。
第八条证据，来自结果衡量。
在企业里，没有哪个 Agent 能长期靠“大家觉得它挺聪明”活下来。 它最后都会被问到这些问题：
- 节约了多少工时
- 提高了多少通过率或转化率
- 降低了多少错误率和升级率
- 缩短了多少流程周期
- 在异常情况下是否稳定
这些都不是纯模型指标，而是业务指标。
所以，把业务视角放在模型视角之前，不是一种偏好，而是一种必要次序。
如果换成一句更短的话：
模型决定 Agent 能做多聪明的判断，
业务决定这些判断是否有意义、是否可执行、是否值得存在。那么，业务视角到底要求我们怎样理解 Agent？ 至少要完成三个转换。
第一个转换，是从“会不会说”转向“认不认识业务对象”。
一个业务型 Agent，首先必须知道它在处理什么对象。 是订单、工单、患者、保单、合同、库存、病例、账户，还是某个设备实例？ 对象不清，后面所有状态、规则、动作都会漂浮。
第二个转换，是从“会不会答”转向“知不知道当前业务状态”。
真正决定下一步动作的，经常不是用户说了什么，而是对象现在处于哪一个状态。 例如：
- 客服场景里，工单是新建、处理中、待补充材料、已升级还是已关闭
- 金融场景里，申请是待审、补件中、风控拦截还是已放款
- 医疗场景里，病人是初筛、待复核、已分诊还是需要紧急转介
没有状态感知的 Agent，再会说也只是表面理解。
第三个转换，是从“会调用工具”转向“会不会在业务责任链里行动”。
业务动作不是抽象动作，而是带责任的动作。 谁有权限执行？ 执行后会影响什么？ 是否需要审批？ 是否要留痕？ 失败后由谁兜底？
只有把动作放回责任链，Agent 才会从“技术动作”变成“业务动作”。
举一个客服 Agent 的例子会很清楚。
一个表面聪明的系统可能会说：
- 我理解您的心情
- 我来帮您查一下
- 这边建议您耐心等待
但一个真正的业务型客服 Agent，必须知道：
- 当前处理的是退货单、补发单还是异常赔付单
- 订单属于哪个履约阶段
- 用户是否属于特殊权益群体
- 当前规则是否允许自动退款
- 哪些情况必须人工复核
- KPI 更重视一次解决率、处理时长，还是风险控制
只有这些问题被建模，系统的动作才会真正有业务意义。
再看研发或运维 Agent。 如果它只是会解释日志、总结报错，那它只是技术助手。 只有当它知道：
- 哪类告警属于 P0、P1、P2
- 哪类服务允许自动重启
- 哪类变更需要 CAB 或人工审批
- 哪些恢复动作影响 SLA
- 哪些系统是只读排查，哪些系统允许写入
它才真正进入业务运维系统，而不是停留在技术表层。
所以，本章真正想建立的，是一个非常朴素但很重要的判断：
业务不是 Agent 的应用外壳，
而是 Agent 的目标定义、状态语义、动作边界、评测标准和风险边界本身。也正因为如此，一个成熟的业务 Agent，通常都不是“更会聊天”的系统，而是“更会嵌入流程”的系统。
它至少要做到：
- 理解真实业务对象
- 理解对象状态变化
- 读取并遵守业务规则
- 在流程中选择正确下一步
- 处理例外而不是只会走理想路径
- 在高风险节点知道停下、交接或请求确认
如果这些做不到，所谓业务适配往往只是词汇适配。
而下一章，我们就要继续拆开这一层最硬的骨架：
为什么业务语义、业务规则、业务流程，会是 Agent 的第一性问题。- 当前客户属于售前、售中还是售后
- 当前诉求属于咨询、投诉、退款还是异常申诉
- 当前是否可以自动解决，还是必须人工接管
- 当前动作会不会带来赔付、承诺或合规风险
一旦这些问题进入系统，Agent 的核心就不再是“话术自然”，而是“流程理解”。
这也解释了为什么业务视角必须放在模型视角之前。
如果一个团队一开始就只讨论模型，而不讨论业务过程，那么最后很容易做出一个“会说很多业务话”的系统，却做不出一个“能推进业务”的系统。