很多企业已经在用 AI：会议纪要一个工具，知识库一个工具，销售跟进又是另一个。每个产品单独看都能用，连到一起却经常失灵。原因通常不在模型，而在模型拿不到同一份业务事实。

工具越多，信息越散

员工知道客户是谁、项目走到哪一步、哪些内容可以对外说。一个刚接入的 Agent 不知道。它看见的是几段聊天记录、一份过期文档和当前输入框里的指令。

这时继续增加插件，只会让问题变得更难排查。销售系统里叫“客户”的对象，在项目系统里可能叫“合作方”；知识库允许阅读的资料，未必允许被复制到外部邮件；某次人工确认的结论，也可能没有写回下一轮任务。

企业 AI 的短板，往往不是不会生成，而是不知道自己正在替谁、依据什么、在什么边界内做事。

中台应连接什么

我们理解的企业 AI 中台，不是一个摆满模型名称的控制台。它更像任务运行时：知道发起人是谁，能找到与任务有关的资料，也清楚哪些动作需要审批。

这层系统至少要处理四件事：

  • 身份和组织关系。 同一句“整理本周客户反馈”，销售负责人和外部供应商能看到的内容不一样。
  • 任务上下文。 Agent 需要客户历史、当前阶段、交付标准和禁区，不该靠操作者每次重新粘贴。
  • 动作权限。 查询、改写、发送、发布、调整预算是不同风险等级，不能共用一个开关。
  • 结果记录。 谁发起、调用了什么资料、执行到哪一步、由谁确认，都应能回看。

这四件事接通后，模型可以替换，工具也可以更换。任务本身仍然在企业的规则里运行。

一个容易忽略的判断如果一个 Agent 只能依靠某位员工记得“应该把哪些资料贴进去”，它还没有真正进入业务。那位员工才是隐藏的中台。

从一个任务开始，不要先接全公司

中台建设最容易掉进“大而全”。先画组织架构、再导入全部文档、最后才想 Agent 做什么，项目会很慢。更稳妥的做法是选一条高频任务链，例如每周经营报告、销售线索初筛或多平台内容发布。

  1. 把任务写清楚。 输入是什么，完成后交付什么，哪些情况算失败。
  2. 圈出最小上下文。 只连接这项任务需要的人、数据表、知识和历史记录。
  3. 拆开读取与执行。 先让 Agent 看懂，再逐步开放写入和外部动作。
  4. 把结果写回去。 人的修改、客户反馈和最终结果都应成为下一次任务的依据。

一条任务跑稳后，再复用相同的身份、权限和记录方式去扩展第二条。这样做不华丽，但企业能看见每一步为什么有效。

息流的实现方式

InFlow X 把组织成员、知识库、SOP、工具连接和任务台账放在同一套工作层里。Agent 接到任务时，先读取对应角色和流程，再调用被授权的工具。需要发布、付款或修改关键数据时，任务停在人工确认点。

我们尤其看重结果回流。一次任务结束后，人的修订不能只留在聊天窗口。它应当更新规则、补充知识或成为新的判断样本。系统因此逐步贴近企业真实的做事方式，而不是反复从一张白纸开始。

企业 AI 中台真正要统一的，不是所有软件的界面。它要统一的是一项任务如何获得信息、取得权限、完成动作，再把结果交回组织。