Drawing the Line Between AI Builders and AI Users

「AI workflow 到底是什么」——这句话最近总在耳边转，同事随口问、群里聊、连刷到的文章标题都在问，每次想张嘴答，又觉得哪里没讲透。脑子里立刻冒出上一篇捋过的那堆词——LLM、RAG、MCP、agent、harness、workflow……可把这些词摆出来念一遍，还是没真正回答上这个问题，反而卡在了更实际的一步：这些东西里，哪些是做工具的人早就实现好、我不用管的，哪些其实是我自己得设计、得练的手艺？这条线不先分清楚，「workflow 到底是什么」这问题就没法算真答上。

第一反应是随手分两堆：听着像技术活的扔一边，听着像技巧的扔另一边。分到第三个词就分不下去了——token 算哪边？它不是谁设计出来的，可我做产品的时候要考虑截断策略，用它的人自己组织输入的时候也得顺着它来，两边都沾，又两边都不完全是。这一下把我原来那套简单二分法冲垮了，只能老老实实一个词一个词过。

有些东西不用你造，但得当硬约束来设计

LLM 本身不用管，那是模型厂商的事，我能做的只有选型——选哪家、多大参数、多少上下文、多少钱一个 token。这件事对做工具的人和用工具的人都一样：谁也没法把模型变聪明，只能挑一个够用的。

token 和 context window 就是前面卡住我的那两个，捋清楚之后发现其实是分工，不是归属。它们是模型天生的物理限制，不是谁「设计」出来的，但做工具的人得把这个限制当成硬约束提前设计进产品里——历史记录超过多少要截断、要不要做摘要压缩、单次调用成本怎么预估；用工具的人则得在这个限制里把自己的任务组织清楚，知道哪些信息值得留、哪些该扔。同一个限制，一边管「系统怎么兜底」，一边管「我这次输入怎么取舍」，谁也不算单独拥有它。

给 AI 接资料、接手、接工具，这是纯粹的工程活

往后翻就顺多了。RAG 这一套——切文档、选 embedding 模型、搭向量数据库、写检索排序逻辑——从头到尾都是做工具的人该干的事。用工具的人不会关心你用的是哪个 embedding 模型，他只会说「AI 怎么连组件库文档都不知道」，剩下的都是你的活。

tool 也一样。给 AI 接上一个外部工具，意味着要写清楚这个工具的参数 schema、怎么校验入参、报错了返回什么格式——这本质上是在给 AI 设计一套 API，跟给人用的接口设计没什么本质区别，只是消费方从人换成了模型。这活儿只能是开发者干。

MCP 更进一步：把已有系统包装成一个 MCP server，让它能被任何支持 MCP 的 AI 客户端发现和调用，这是标准的协议实现工作，得写代码。用工具的人只需要决定「要不要装这个 MCP server、给它多大权限」——这已经是使用者那边的判断了，跟怎么实现 MCP 无关。

顺带一提，前面那道「MCP 和 CLI 有什么区别」的面试题，本质上问的正是这条分界线：CLI 是给人用的接口，MCP 是给 AI 发现和调用能力的协议——一个服务使用者，一个服务开发者。

不闯祸、能成事，这两件事也轮不到使用者操心

harness engineering 和 loop engineering 是这条链里工程属性最重的两个词。权限控制、工具白名单、执行沙箱、人工审批、回滚机制、自检复盘、自动重试——这些全是要写进系统里的控制逻辑，没有哪个使用者能在对话框里临时给 agent 「配一个沙箱」。企业要用好 agent，这两块必须有人事先搭好，搭的人就是开发者。

我一开始下意识觉得，只要 prompt 写得够好，agent 自然就不会闯祸——琢磨了一会儿才反应过来这是两回事。prompt 决定的是「这次要它干什么」，harness 和 loop 决定的是「不管这次要它干什么，系统兜不兜得住」。前者是使用者的活，后者从一开始就不是使用者能管的范围，写多好的 prompt 也补不上系统层面的窟窿。

剩下这几个词，机制是开发者的，内容是使用者的

到这儿本来以为分类已经理顺了，结果 context engineering、skill、agent、workflow、workspace agent 这五个词一个个都不肯乖乖归边——每次刚想把它们塞进「开发者」那一堆，就发现总有一半不对劲。琢磨了一阵才想明白：这五个词根本不是一个整体，是两半拼出来的，一半机制一半内容，硬要归一边才是我想错了。

context engineering 的「能不能把历史对话、用户资料、工具结果动态拼进这次请求里」，是开发者要写代码搭的信息管道；但「这次任务到底该不该带上历史对话、该不该带公司规范」，这个判断往往需要懂业务的人来定——可能是开发者，但更多时候是产品或者使用场景本身决定的，纯技术视角未必判断得准。

skill 也是这个结构。「能不能把一套指令存下来、下次直接复用」，这是平台该提供的机制；但这份 skill 里具体该写哪些规范、覆盖哪些边界情况，是每个使用者根据自己团队的实际情况填进去的内容。同一个 skill 系统，你的团队和别的团队存出来的东西可以完全不一样，这部分没法由开发者替你想好。

agent 的循环——先计划、再动手、看结果、调整下一步——这套引擎是开发者写的；但「这次任务要不要用 agent、给它多大自由度、目标该描述到多细」，是使用者每次都要重新判断的事。同一个 agent 引擎，配上一句含糊的目标和一句讲清楚边界的目标，出来的结果能差出十万八千里，而这个差距不是引擎能弥补的。

workflow 同理：n8n、扣子这类平台是开发者搭的执行引擎——节点系统、触发器、调度逻辑；但「这条流程该怎么设计、遇到什么情况走哪个分支」，是懂业务的人根据实际场景编排出来的，跟平台本身没关系。

workspace agent 的底层能力——权限隔离、数据同步、长期记忆的存取——是开发者要解决的工程问题；但「谁该看到什么信息、什么时候该转人工、哪些数据该留多久」，这是组织和流程设计问题，通常落在使用这个 agent 的团队或管理者身上，写代码的人给不出答案，因为这背后是权责划分，不是技术判断。

使用者自己的手艺，谁也替不了

prompt 是最典型的使用者手艺——同样的模型、同样的任务，讲得清楚和讲得含糊，结果天差地别，这事从头到尾都是使用者自己练出来的，跟开发者没关系。

vibe coding 更彻底，它压根不是一个「要不要开发」的东西，而是一种工作方式的转变——从自己写实现，变成描述目标、验收结果。这件事没有任何代码能替你完成，只能自己在实践里慢慢调整节奏：什么时候该放手让 agent 去跑，什么时候该打断它重新给方向。

一条大概能记住的分界线

绕了这一圈，勉强摸出一条规律：凡是「能不能做到」的问题，几乎都归开发者——模型能力、检索管道、工具接口、协议实现、安全兜底、执行引擎；凡是「该不该这么做、该做到什么程度」的问题，几乎都归使用者——任务怎么讲清楚、边界怎么定、权限怎么分、流程怎么编排。中间那几个卡了我半天的词，拆开看无非是「开发者搭好机制，使用者往里填内容」。

术语	开发者要做的	使用者要做的
LLM	—（模型厂商的事）	选型
token / context window	按限制设计截断、成本策略	按限制组织输入
RAG / embedding	搭建检索管道	—
tool	设计工具接口	—
MCP	实现 MCP server	决定是否接入、授权范围
context engineering	搭建信息管道	决定塞什么信息
skill	提供复用机制	写具体规范内容
agent	写循环引擎	设定目标与自由度
vibe coding	—	转变工作方式
harness engineering	权限、沙箱、审批、回滚	—
loop engineering	自检、重试、进度追踪	—
workflow	搭建执行引擎	编排业务逻辑
workspace agent	权限隔离、记忆存取	设计权限与流程规则

拿 Codex 举个例子，落一下地

说了这么多分类，不如摊开一个具体场景验证一下：假如现在真开一个 Codex，接到项目里干活，上面这条线到底怎么套？

LLM、token/context window、RAG（它自己会去读代码库）、tool（跑命令、改文件、跑测试）、MCP、harness（沙箱、权限审批）、loop（改完自己跑测试、看报错、再改一版）——这些 Codex 已经内置好了，装上就能用，我不用也没法管底层怎么实现的。这一层，前面捋的规律直接成立：能不能做到，从头到尾不是我的事。

真正落在我头上的，是剩下这几件：

• 项目里有没有一份说明文档告诉它目录结构、代码风格、测试怎么跑——没有的话它连「组件命名用什么规则」都得瞎猜，这是 context engineering 里内容那一半，它自己填不出来。
• 任务怎么描述。「优化一下这个组件」和「给 Button 加个 loading 状态，参考 Modal 已有的写法，改完跑一下现有测试」，效果能差出天际——这就是 prompt，谁也替我练不了。
• 权限模式开到哪一档：每一步都要我确认，还是让它自己跑完再看结果——这是 harness 留给我的那个开关，机制是 OpenAI 搭的，开到哪一档是我的判断。
• 项目里测试够不够、覆盖不覆盖边界情况——它的 loop 能自己跑测试改代码，但前提是有测试可跑，测试写得糙，它改出来的东西照样糙。
• 要不要让它自动开 PR、接 CI、等 review——这条 workflow 编排，还是得我自己接。

绕一圈下来发现，Codex 把「怎么做到」这层全包了，真正没人能替我做的，永远是「这次到底想让它干什么、干到什么程度」。工具越强，留给我的东西反而越纯粹，全是判断力的活，躲不掉。

回头再看「AI workflow 到底是什么」这句话，问的其实从来不是一个词的定义——它问的是这套系统里，哪部分是别人早就搭好的引擎，哪部分永远得自己往里填内容。这条线是不是画得准，等真接了需求再验证，反正下次再被问起，至少不会张口结舌了。