当系统开始理解业务

AI Native Company #05

上一篇我们谈到，当 AI 能力变化越来越快，业务本身也开始成为变量。接下来还有一个很现实的问题：这样的业务，该怎么做成系统？

传统企业系统有一套成熟的方法。从业务出发，梳理 Business Process，分解成 BFC（业务功能），再转换成对应的 SFC（系统功能），之后进入应用、基础设施、安全、运行、运维等架构设计。

这套方法不会因为 AI 出现就失效。但其中一个长期存在的问题，正在变得更加明显。

从业务需求到 BFC，再到 SFC、设计、代码和测试，每往下一层，都发生了一次语义翻译。业务人员理解业务，架构师理解系统，开发看到 User Story，测试验证 Expected Result。最后可能每个 SFC 都做对了，系统也顺利上线，业务仍然觉得“不太是我要的东西”。

Business Intent 在这个过程中一点点丢掉了。

AI 可以更快地开发 SFC，却未必天然解决这个问题。

从 BFC 到 SFC，多了一步

过去看到一个 Business Function，我们很自然地开始考虑需要哪些画面、API、Batch 和 SFC。

Agent 出现以后，可以先多问一个问题：

这项工作应该怎样执行？

比如“处理一个订单延期”。

过去可能把它拆成查询订单、查看物流、计算补偿、修改交期、通知客户等 SFC，再通过画面和 Workflow 让人完成整个过程。

现在 Agent 可以直接理解“处理这个订单延期”这个 Job，获取订单和物流信息，读取补偿规则，根据上下文判断下一步，再调用 ChangeDeliveryDate()、IssueRefund()、NotifyCustomer() 等系统能力。

这个过程里，Agent 负责理解意图、判断和组合路径；SFC 负责完成明确、可测试、可审计的动作。

Agent 处理模糊性，SFC 保持确定性。

BFC 和 SFC 之间因此多了一个 Execution Design：先决定这项工作由 Human、Agent、Rule、Workflow，还是它们的组合完成，再决定下面需要怎样的系统能力。

概念示意，点击图片查看大图。

Palantir：让 Agent 看到业务

这里最难的其实不是让 Agent 调 API，而是让它理解 API 背后的业务。

企业里已经有 ERP、CRM、MES、数据库和大量接口。直接把这些交给 Agent，它看到的是 Table、Field、Object 和 Endpoint，并不等于理解企业怎样运行。

Palantir 的 Ontology 提供了一个很有参考价值的做法。

它把分散在不同系统里的数据、逻辑和操作重新表达成 Customer、Order、Supplier、Shipment 等业务对象，以及修改订单、调整配送、处理风险这样的 Action，并把 Security 一起放进这套业务表达中。

Agent 因此面对的是一个可以理解和操作的业务世界，而不只是底层系统。

这也给传统 BFC / SFC 方法一个启发：Agent 需要的不只是更多 Context，还需要 Business Semantics。

过去在 BFC 到 SFC 之间容易丢失的业务语义，可以继续留在 Agent 的运行环境里。

OpenAI：执行路径进入 Runtime

理解业务以后，Agent 还需要一个持续工作的运行环境。

OpenAI Agents API 的架构把 Harness 与执行 Environment 分开。Harness 负责 Agent loop、Session、Context、Tool、Subagent、Approval、Trace、Recovery 等能力，具体的代码和命令则可以在独立环境中执行。

这带来另一个变化。

过去很多执行路径在设计和开发阶段已经固定在 Application 和 Workflow 中。Agent 可以根据当时的 Context，动态选择 Tool、调用 Subagent、等待 Approval，或者改变执行路径。

因此 Harness 很难简单归入传统架构里的某一个分类。它同时涉及 Application、Development、Execution、Security 和 Operations。尤其是 Execution Architecture，一部分设计开始从 Design Time 延伸到 Runtime。

Google：Agent 也成为架构的一部分

当企业里出现越来越多 Agent，它们还需要使用其他系统和彼此协作。

MCP 让 Agent 以标准方式连接 Tool 和 Context；Google 推动的 A2A 则解决不同 Agent 之间的发现、通信和任务委托。

企业架构原来主要考虑 Application、Service 和 API 之间的连接，现在多了 Agent 与 Tool、Agent 与 Agent 的关系。

Agent 开始成为架构中的正式参与者。

概念示意，点击图片查看大图。

AI Native Zone 里的系统

把这三个实践放在一起，AI Native Zone 里的系统设计可以尝试这样的设计路径：

Business Intent → Process → BFC → Execution Design → Agent / Human / Rule → Business Semantics → SFC / Action → System of Record

概念示意，点击图片查看大图。

传统架构仍然在下面发挥作用。ERP、CRM、MES 继续保存交易和事实；SFC 继续提供确定性的系统能力；Infrastructure、Security、Operations 仍然支撑整个系统。

变化发生在上面。

Business Function 不必过早固化成固定 Workflow 和一组面向人的系统功能。Agent 可以保留更多 Business Intent，在运行过程中根据 Context 组合已有能力。SFC 也开始从“人通过画面使用的功能”，变成 Human、Application 和 Agent 都可以调用的企业能力。

这甚至可能反过来改变 SFC 的设计：功能更原子化，输入输出更明确，权限、事务、失败处理和审计边界更清楚，让不同的执行者都能安全使用。

过去做系统，很大一部分工作是在把业务逐层翻译成软件。

Agent 带来的一个可能性，是让最初的 Business Intent 不必在翻译完成后消失，而是继续存在于 Context、Runtime、Action 和 Eval 之中。

如果这一点成立，AI Native Architecture 真正改变的，也许不只是系统里多了一层 Agent。

它开始重新连接 Business Intent 与最终运行的系统。

本文配图为 AI 生成的概念示意。