企业 AI：任务、Artifact 与交付

一个企业需求经常这样到来：几句口头描述、几张产品图片、一份旧表格，再加一句“能不能先给我一个可以执行的方案”。

模型可以很快整理出一段像样的回答。工作却才刚开始。图片中的规格是否可信，缺失字段由谁补充，价格来自哪套规则，哪个版本可以发给客户，最终文件又由谁确认——这些问题不会因为语言更流畅而消失。

我后来更习惯从交付物倒推产品。先确认最后需要被检查、批准、发送、生产或审计的对象，再决定对话、模型、规则与人工分别承担哪一段工作。

这条路径得到的企业 AI 不一定最像聊天机器人，却更接近企业真正愿意重复使用的系统。

一项任务远大于一段对话

一个客户需求通常始于语言、文件、图片、默认假设与缺失信息的混合体。对话很适合消除这些模糊，但它不足以承载完整的工作。

一项任务需要长期存在的事实：

• 用户究竟想完成什么；
• 哪些输入已经被确认；
• 哪些规则与约束正在生效；
• 哪些动作已经执行；
• 哪一个结果才是当前版本；
• 谁批准了下一项会产生后果的操作。

如果这些事实只存在于聊天记录里，产品就等于把自己的状态模型交给了自然语言。它看起来灵活，却很难恢复、审计，也很难稳定运行。

因此，我更相信以任务为主、对话发生在任务之中的产品，而不是以聊天为主、任务藏在消息背后的产品。

报价任务能很好地暴露这种区别。模型可以从材料中提取规格、发现缺失项并生成解释；确定性计算负责应用价格与业务规则；审核者确认例外；最终报价则以一个明确版本被交付。对话推动信息变得完整，但后续执行依赖的是那份被确认的 Artifact，而不是聊天里最后一条看起来最完整的消息。

模型应该翻译边界

语言模型在系统最不确定的边缘非常有价值。它可以理解描述不完整的目标，阅读陌生材料，发现缺失输入，并整理出结构化草稿。

但这并不意味着模型应该成为事实来源。

只要业务已经对价格、资格、风险规则、审批要求、副作用与生产文件拥有明确定义，它们就应该由确定性系统负责。模型可以解释这些系统，帮助用户与它们交互，却不应该用一段看似合理的文本悄悄取代它们。

更可靠的职责划分是：

• 模型负责理解与提出建议；
• 产品负责确认与记录；
• 规则和服务负责执行；
• 人负责批准真正会产生后果的决策。

它没有“让一个模型包办一切”那么神奇，却更容易被信任。

交付物承载价值

最重要的输出通常不是 Assistant Message，而是工作产生的 Artifact：一份报价、报告、Brief、计划、审阅过的数据、生产文件或决策记录。

Artifact 拥有消息天然不具备的属性。它可以被版本化、比较、批准、驳回、下载、交给另一个系统，并且能够追溯到生成它的证据与规则。

对话依然重要，但它是协商意图、解释决策的地方。Artifact 才是价值持续积累的地方。

这个区分也会改善界面。用户不必在漫长的时间线里寻找最新答案，产品可以直接展示当前结果、所处状态、依据，以及下一项需要做出的决定。

人工审核是架构的一部分

Human-in-the-loop 经常被当作一种临时妥协：模型还不够好，所以暂时增加一个人工步骤，未来再把它去掉。

在企业工作里，这种理解是错的。审核是责任变得明确的方式。

一个有用的系统应该说清楚：

• 哪些字段来自用户、来源文件、规则或模型；
• 哪些假设仍然不确定；
• 哪个动作会对外部世界产生影响；
• 谁确认了这次决策；
• 驳回或修正之后发生了什么变化。

目标不是更频繁地打断人，而是在权限、模糊性与后果交汇的地方，准确地引入人的判断。

复用发生在交付之后

我们很容易产生一种冲动：先做一个通用平台，一套万能专家构建器、Workflow 引擎或者 Agent 市场。但企业之间的差异并不是等待被抽象掉的噪声，它们往往就是业务本身。

真正可复用的层，应该从一次次实际交付里长出来。身份、任务状态、审计、Artifact、模型访问与执行基础设施可能具有共性；定价规则、生产约束、审批语言、模板和例外处理，通常属于具体 Solution。

因此，平台能力的判断标准不是它暴露了多少配置，而是下一个真实 Solution 能否在不破坏业务边界的前提下，更快完成交付。

商业证据存在于模型之外

企业最终购买的不是 Agent。它购买的是更短的处理周期、更少的错误、更快的新人上手速度、更一致的决策，或者一条终于可以被检查的流程。

这也是评估产品最诚实的方式。

真正困难的问题不是系统能调用多少 Tool，也不是 Demo 看起来多么惊艳，而是人们是否会回来重复完成同一项任务，Artifact 能否经受真实审核，例外是否更容易处理，以及下一次交付是否比第一次更便宜。

当智能不再是最终输出，而是成为一套能够交付可问责工作的系统组件时，企业 AI 才真正变得耐用。