【AI架构】数据、行为与 AI：传统信息系统接入 Agent 平台的两条路

Fri, 18 Sep 2026 13:07:00 +0800

传统信息系统只有两个元素：数据和行为。数据是表和文件，行为是围绕数据的增删改查和业务规则。三十年来技术栈换了好几轮，信息系统的骨架一直是这两样。

现在多了第三个元素：AI。它和前两个在性质上不同：数据是确定的，行为是确定的，AI 是不确定的。它读数据、调行为，还会自己决定下一步调哪个。所以"AI 放在系统的哪个位置"这个问题，在技术上只有一个含义：控制流归谁。 是系统决定什么时候用 AI，还是 AI 决定什么时候用系统。

这正是这几年吵个不停的 Agent 模式与 Workflow 模式之争。我原本以为它是个理念问题，直到自己做了一个小应用，发现它落到代码里是一组非常具体的架构取舍。

一、出发点：一个小应用

我有一台跑着 ComfyUI 的远端主机，上面有一个图生视频工作流。之前每次出片都要手动上传图片、粘提示词、改参数、排队、下载，同一张图试过哪些提示词、哪条效果好，全靠笔记。

于是我花几天做了个本地应用。它把物料组织成一棵树：一张图片下挂多条提示词，一条提示词下挂多次生成任务，每个任务对应一个视频。生成走自己的串行队列，完成后把视频拉回本机。写提示词的活交给一个能看图的"管家"智能体，它理解我沉淀的带变量的元提示词模板和项目里的 SKILL，产出的提示词直接存到图片下。我再用五星评分作为评价体系。

按三元素拆开：

数据：图片、提示词、任务、评分，以及它们之间的谱系。
行为：生提示词工作流、生视频工作流、评价打分。
AI：管家，看图写提示词。

它是一个"传统信息系统 + 一个 AI 附件"的教科书样本。功能齐了，我却觉得哪里不对。

二、思考点：逐项对齐到 Agent 平台

不对的地方在于，深挖每一项基本功能，几乎每一项在现有的 Agent 平台上都有对应物：

我做的	平台上的对应物	平台能否替代
元提示词的 `{{变量}}` 模板	Dify、Coze 的提示词变量	能
管家的"对话 + 工具 + SKILL"	Agent 节点 + 工具插件 + Skills 目录	能
串行队列、失败重试、超时兜底	工作流引擎的执行器	能
参数表单由配置生成	工具节点的参数 schema	能
图片 → 提示词 → 任务的物料树与谱系	无	不能
五星评分与按评分排序	无	不能
带类型参数映射的 ComfyUI 调用	只有"扔整个 JSON"的粗粒度插件	勉强

只有三样东西平台没有：物料的管理，评分体系，和一个像样的 ComfyUI 调用节点。 换句话说，我做的不是一个产品，是一个平台插件加一个数据库。

这个发现的第一层结论是业务模式的对齐：与其自己重造对话界面、工作流引擎和模板系统，不如交给平台，自己只做平台缺的那些。第二层是商业价值的对齐：放进平台，价值来自被调用和被分发，而不是来自入口。这一层是商业判断，本文不展开。

对齐之后，真正的技术问题才浮出来：数据平台和 Agent 平台，谁持有控制流？ 这个问题有且只有两个答案。

三、方法论：两条路线，两种模式

先把两个词说清楚。Workflow 模式是人写控制流，模型填节点；Agent 模式是模型写控制流，人给工具和目标。区别只有一个：谁决定下一步。

一个已有的数据管理平台要和 Agent 平台结合，两条路正好对应这两种模式。

路线一：数据平台为主，Agent 平台供给工作流（Workflow 模式）

拓扑是数据平台 → API → Agent 平台上发布的应用。信息系统保持主体：它拥有界面、流程和事务边界。AI 能力从平台购买：Dify 的应用发布成接口，Coze 的 Bot 发布成接口，n8n 的工作流挂一个 Webhook。信息系统在流程里预留的位置上调一下，拿到结果继续走。

技术上要处理的事情：

契约是固定的。 平台上的应用被当作一个纯函数：输入是图片和实例化后的模板文本，输出是一组提示词的 JSON。schema 由数据平台定义，平台应用照着填。
上下文由数据平台组装。 图片缩放、转 base64、模板渲染、已有提示词列表，全部在调用前准备好。AI 只看到这一次调用需要的东西，上下文天然最小化。
同步或异步由数据平台决定。 短任务阻塞等结果，长任务用平台的回调或 SSE，但状态机始终在数据平台这边。
写回在数据平台的事务内。 结果落库、幂等、失败回滚，都是信息系统自己的事，平台不参与。
供应商可抽象。 一个 provider 接口，Dify、Coze、n8n 各是一个实现，切换不动业务代码。

对应到我的小应用：界面和账本不变，管家不再自己跑 LangChain，而是把图片和元提示词发给 Dify 上的一个 Agent 应用，拿回提示词存进账本。生视频工作流照旧走自己的串行队列，评分照旧。

这条路的特征：

稳定。 每一次 AI 调用都在系统自己的事务边界内，出了问题在自己的日志里查。
数据不出门。 AI 只看到你传给它的那一小段上下文。
基本没有扩展性。 AI 只能做系统预先留好位置的事。每一个新的 AI 用例，都要在数据平台开一个新入口、写一段新逻辑，再到 Agent 平台新建一个应用。AI 在这里做的是填空题，题目是系统出的。
无法跨系统组合。 AI 看不到这个系统之外的任何东西，也看不到这个系统的全貌。

路线二：Agent 平台为主，数据平台以 MCP 供给数据与行为（Agent 模式）

拓扑反过来：Agent 平台 → MCP → 数据平台。信息系统退到后面变成无头服务，通过 MCP 把自己暴露出去。对话和编排在平台上发生，信息系统只回答"给我这个"和"帮我做这个"。

MCP 的三个原语和信息系统的三元素几乎一一对应：

数据 → resources。 图片、提示词、任务以资源暴露。图片作为资源之后，平台上的多模态模型可以直接读图，“管家看图"不再需要自己维护。
行为 → tools。 账本的增删改查、打分、建任务、查状态、取消。每个 ComfyUI 工作流按参数映射生成一个 tool，映射文件里的类型、范围、默认值直接转成 JSON Schema，平台自动拿到带校验的表单。
方法论 → prompts。 元提示词天然对应 MCP 的 prompt 原语，{{变量}}、枚举、默认值原样映射成 arguments。SKILL 目录也可以作为 prompts 或 resources 暴露。

技术上要处理的事情，比路线一多得多：

长任务要改形态。 MCP 工具是请求响应式的，生视频不能靠一次调用等完。建任务立即返回 ID，再提供一个查状态的 tool 让平台轮询，或者用 MCP 的 Tasks 扩展。串行、取消、重启恢复这些语义仍然留在数据平台，藏在工具后面。
副作用要标注。 哪些工具只读、哪些有副作用、哪些不可逆，要通过 tool 的注解告诉平台。“管家不允许直接建任务"这条约束，在这里变成不暴露那个 tool，或者在 tool 上加审批开关。
schema 要写给模型看。 工具的名字、描述、参数说明，决定了模型会不会用、用得对不对。这是一种新的 API 设计，面向的读者不是程序员。
传输与鉴权要补。 平台只认 Streamable HTTP。原来跑在本机没有鉴权的服务，接任何非本机平台前必须加 token 或 OAuth。局域网可达性也要重新考虑。
系统要无头化。 前端从主角降级为账本管理台，评分、谱系这些需要界面的能力保留在自家前端，对话与生成的入口交给平台。
幂等要显式。 模型可能重试、可能重复调用，每个有副作用的工具都得能安全地被调两次。

对应到我的小应用：管家退位，平台的 Agent 节点接上 MCP 之后就是管家。自家后端变成"素材与实验账本服务”，参数映射机制以 tool 的形式暴露，串行队列藏在建任务的 tool 后面。

这条路的特征：

可迁移性极强。 一份 MCP 实现，Dify、n8n、Coze、Claude、ChatGPT 全能接，不押注任何平台。
用例开放。 AI 能做什么不再由系统预先规定，而由它拿到的工具和上下文决定。跨系统组合成为可能：一个 Agent 同时拿着你的账本工具和别人的网盘工具。
改动不小。 上面那六条不是加功能，是重构边界。
控制力不高。 什么时候调、调几次、按什么顺序调，由平台上的模型决定。审计日志一半在你这、一半在平台。工具返回的内容对模型来说是数据，但模型可能把它当指令，注入面从界面转移到了工具返回值。

两条路是镜像

把两条路并排放，每一个维度都是相反的：稳定对开放，控制对迁移，改动小对改动大，上下文最小化对上下文由模型决定。路线一放弃的是 AI 的可能性，路线二放弃的是对控制流的主权。 没有一条能在所有维度上占优。

实践里还有两种混合形态，值得单独说：

路线二上补路线一的控制平面。 在 MCP 前面加一层网关：统一鉴权、统一审计、工具白名单、对高风险工具加审批。控制流仍然归模型，但每一步都经过你的检查点。
路线一上开一个只读的 MCP。 系统主体不变，但把数据以 resources 暴露出去，让外部 Agent 能看不能改。扩展性补回一部分，主权不丢。

四、观察产业现状：所有人都在两条路上同时走

这场争论在产业里打了两年多，几条线索都很清楚。

Agent 平台自己在两条路上同时走。 Dify 在 1.6 之后既能把 MCP 当工具接入，也能把自己的应用发布成 MCP。n8n 同时有 MCP 客户端节点和 MCP Server 触发器。Coze 也加了 MCP 插件。这意味着平台既是路线二的宿主，也是路线一的供应商：它接你的 MCP，也让你以 API 调它。平台没有替你选边，它两边都要。

MCP 规范在主动补路线二的短板。 今年 7 月的版本把协议改成无状态，让普通 HTTP 基础设施能直接承载；引入 Tasks 扩展处理长时任务；引入 MCP Apps 扩展让服务端能渲染界面。我在上一篇文章里把这些当作"协议往系统调用层沉"的证据。换个角度看，它们恰好对应路线二最被诟病的三个问题：状态、长任务、没有界面。协议在降低走路线二的代价。

Skills 的标准化把"方法论"变成了文件格式。 SKILL.md 是给 Agent 读的方法论文档，正好落在 prompts 这一层。我的小应用里那个手工维护的 skills 目录，在路线二下不需要任何改造就能被平台的 Agent 读到。

SaaS 厂商的轨迹是从路线一走向两条并行。 2023 到 2024 年几乎全行业在自己界面里嵌 Copilot，AI 是一个功能点，用例由厂商枚举。2025 年 MCP 定型之后，同一批厂商成批发布官方 MCP Server：GitHub、Atlassian、Notion、Stripe、Cloudflare、Linear、Sentry、Figma。路线一守自己的入口，路线二在别人的入口上不缺席。

企业内部在用网关找回控制力。 路线二最大的代价是控制力流失，于是 MCP 网关这类东西开始出现：统一鉴权、统一审计、限流、工具级授权，所有 Agent 平台对内部系统的调用都经过它。这就是上面说的第一种混合形态在企业里的落地。

分界线每一代模型都在往路线二移，但路线一没有消失。 Anthropic 2024 年底那篇讲如何构建 Agent 的文章立场很明确：能用工作流解决的就不上 Agent，Agent 留给步骤无法预先写出来的任务。两年过去，这条线的位置变了，原则没变。变化的原因有两个：模型越强，写不出 SOP 的任务越多能直接交给 Agent；同时 Agent 让写工作流变得极便宜，让 Agent 探索几次，把稳定下来的路径固化成工作流，成本降了一个数量级。Agent 越强，工作流反而越多，因为 Agent 成了工作流的生产者。

把这些放在一起：平台两条路都走，协议在补路线二的短板，企业在路线二上加控制平面，模型能力在把分界线往路线二推，但路线一始终是生产环境的默认。 争论没有结束，格局已经稳定。

五、最终结论：没有结论，只有场景

写到这里，读者大概期待一个"所以应该选哪条"的答案。我没有。两条路的代价都是真实的，没有一条在所有场景下占优。能给出的只有判断变量，而且都是技术变量。

用例能不能枚举。 能枚举的，路线一够用，AI 只需要在几个明确的位置做明确的事。不能枚举的，只能走路线二，路线一的填空题模式会把"事先没想到的组合"这部分价值全部锁死。

副作用的比例和可逆性。 系统里的行为大多只读或可逆，路线二的控制力损失可以接受。行为大多不可逆、事务要求强，路线一或者带网关的路线二。

有没有便宜的验证器。 编程有编译器和测试，Agent 的每一步都能被当步验证，所以编程领域最早全面走路线二。图生视频没有便宜的验证器，好不好只有人看了才知道。这时候人工评分就是验证器，账本就是验证器产生的数据。没有账本，Agent 的探索没有沉淀的地方。这也是为什么评分体系必须留在数据平台，不能交给 Agent 平台。

需不需要多平台。 只接一个平台，路线一的供应商抽象够用。要同时被多个平台调用，路线二的一份 MCP 实现是唯一不重复劳动的办法。

对照到我自己的小应用：用例完全开放，我自己都说不清管家下一步该帮我干什么；账本的行为大多可逆，不可逆的只有删除，可以不暴露；验证器是我自己的评分，留在账本里；将来大概率要同时接 Dify 和 n8n。四个变量全部指向路线二。所以它会变成一个 MCP 服务，账本、评分和参数映射留在自己手里，对话和编排交给平台。

但生视频那条链路我会继续用 Workflow 模式跑：参数映射定义节点绑定，串行队列保证可预测，任务快照保证可追溯。它是路线二里的一个 tool，tool 的内部是路线一。Agent 模式探路，Workflow 模式跑量，评分是两者之间的沉淀通道。 管家试出的高分提示词，抽象成带变量的元提示词模板，下次就不需要管家了。

换一个场景，比如一个流程固定、审计严格的内部系统，四个变量全部反转，它应该走路线一，把 Agent 平台当作供应商藏在自己的流程后面。

结语

“AI 该放在信息系统的哪个位置”，答案是"控制流归谁”。Workflow 模式把控制流留给系统，换来稳定和可控；Agent 模式把控制流交给模型，换来开放和可迁移。两条路各有真实的代价，每个系统都得按自己的场景选，或者像平台那样两边都站。

我能给的唯一通用建议是：不管选哪条，先把数据和行为整理成平台无关的接口。 路线一需要它来隔离供应商，路线二需要它来暴露 MCP。它是两条路唯一的公共前提，也是唯一不会因为选错路而浪费的投入。

Workflow on 雨的味道