传统信息系统只有两个元素：数据和行为。数据是表和文件，行为是围绕数据的增删改查和业务规则。三十年来技术栈换了好几轮，信息系统的骨架一直是这两样。
现在多了第三个元素：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。它是两条路唯一的公共前提，也是唯一不会因为选错路而浪费的投入。