你有没有遇过这种“听起来很专业、但就是不对劲”的追问：你刚说完需求，对方第一句就丢回来——“你用 LangChain 还是 CrewAI？”
我前阵子帮老大整理一套内容工作流的提示词，原需求其实很朴素：把资料拼成一篇能直接发布的 Markdown，外加一个给下游节点用的 JSON 摘要。结果模型把第一轮对话变成了框架选型会，连“标题要不要 frontmatter、字段要不要校验”都没问。
我当时卡了一下：是不是我太敏感？话说回来，问框架当然不是原罪，但它出现在第一轮，往往意味着一件事——交付边界还没想明白。
会先追问“你用 LangChain 还是 CrewAI”的 AI，通常不是严谨，而是还没把交付边界想明白。
你明明只想要一篇 Markdown、一段 JSON，或者一个能直接贴进工作流的结果，它却把话题拐到“调用方所使用的编排系统”。这就像你找人装空调，对方还没看房间面积、没问你几匹、没确认电压，先问你家开关面板是哪个牌子。不是完全没关系，但顺序错了。
这类输出我这阵子看得有点多。表面上它在“考虑兼容性”，实际上暴露的是另一件事：**任务层、适配层、运行层，全被它搅成一锅了。**最后的结果往往也很熟悉——提示词越来越长，框架一换就散架，真正要交付的内容反而没人说清楚。
为什么 AI 总爱先问你用 LangChain 还是 CrewAI？
因为它分不清自己到底是在“完成任务”，还是在“扮演某个框架里的 Agent”。
先把名字摆出来：
LangChain、AutoGen、CrewAI 都是常见的多智能体编排方案。它们确实有差异：消息怎么传、工具怎么注册、状态怎么存、谁来收尾，都不一样。
但有个经常被忽略的点是：大多数内容生成任务，和框架强绑定的部分，远比你想象得少。
如果你要的交付物只是：
- 一篇 Markdown 文章
- 一段结构化 JSON
- 一份 PR（代码提交审核）说明
- 一份研究摘要
- 一套客服话术
那模型更应该先确认的不是“你底下跑的是哪套编排”，而是：
- 我最后要吐出什么？
- 我能不能调工具？
- 失败时怎么收？
很多提示词会翻车，就是因为把“框架差异”错当成了“任务前提”。
多智能体编排里，真正该先确认什么？
先定输出契约，再定工具边界，最后才是框架适配。
这段你可以直接转给同事：
多智能体编排里，LangChain、AutoGen、CrewAI 更像插座型号，决定的是消息路由、工具注册和状态管理；真正应该先确认的，是输出契约：要交付什么格式、能不能调用工具、失败怎么降级、谁负责最后验收。先定契约，再做适配，提示词才不会一换框架就散架。
我把这事拆成三个层，你会看得更清楚。
| 层级 | 先确认什么 | 典型内容 | 该不该先问 |
|---|---|---|---|
| 任务层 | 交付结果 | Markdown、JSON、摘要、清单、FAQ | 该先问 |
| 适配层 | 接到哪里 | LangChain、AutoGen、CrewAI、自研工作流 | 后问 |
| 运行层 | 怎么执行 | 工具权限、超时、重试、日志、密钥 | 最后补 |
顺序感很重要。
你先把任务层钉死，后面换框架只是“换插座”；你如果一开始就把框架写死，后面每次迁移都像把整面墙重新砸开。
这也是我判断很多团队提示词越写越脏的根源：他们以为自己在做“能力增强”，其实是在把适配细节偷渡进业务逻辑。
框架差异到底差在哪，哪些地方不用提前纠结？
不是说框架不重要。它重要，但重要在另一层。
| 维度 | LangChain | AutoGen | CrewAI | 自研/直连 |
|---|---|---|---|---|
| 强项倾向 | 链路和工具编排 | 多角色对话协作 | 角色分工与流程表达 | 可控、轻、贴业务 |
| 你更常操心的事 | 节点和状态流转 | 代理间对话边界 | 任务拆分与角色定义 | 接口契约与异常处理 |
| 真正影响生成结果的点 | 输出格式校验 | 轮次控制 | 角色提示词设计 | 业务规则写得清不清 |
| 对内容任务最关键吗 | 不是第一位 | 不是第一位 | 不是第一位 | 也不是第一位 |
说白了，框架影响的是“怎么接线”，不是“电器本身要干嘛”。
如果一个生成任务连“输出什么格式”都没说清，就急着问 LangChain 还是 CrewAI，这基本等于电饭煲还没说要煮饭还是煲汤，先讨论你家插线板有几个孔。
这段听着像吐槽，但真落到交付里，坑非常具体。
我见过最常见的失控路径是：你允许模型把框架问题提到最前面，它就更容易把“工具调用约定”“消息格式”“路由细节”写进正文。内容团队拿不到能直接发的稿子，开发团队拿不到稳定的结构化结果，两边都觉得它说了很多，实际一个都没交付完整。
还有一个事我不敢把话说太满：有些团队确实需要在第一轮就锁定框架，比如你就是在写某个框架的执行代码。只是现实里，这种情况在“内容工作流”占比没那么高，至少在我接触的项目里是这样。
一套不容易散架的写法，应该怎么拆？
我更建议把多智能体提示词拆成两份：任务契约 + 适配备注。
这不是学院派讲究，是为了以后少返工。你把“交付”先钉住，模型就不容易跑去讨论“接线姿势”。
第一层：任务契约
这里解决“你到底要交什么”。
至少写清 5 件事：
-
目标产物
比如：输出一篇 Markdown 博文；输出一个 JSON 数组；输出飞书可直接粘贴的周报。 -
硬格式
标题、字段、段落结构、是否允许代码块、FAQ 格式、是否要 frontmatter。 -
允许能力
只能纯文本生成，还是允许引用外部工具结果；能不能调用 API；能不能输出工具标签。 -
禁止事项
不要编数据，不要暴露思维链，不要输出 XML 工具标记，不要问无关澄清问题。 -
失败降级
信息不够时怎么做：标注待确认、给出占位、列缺口，但先交付主体。
你会发现，这五件事里，没有一件必须先知道你跑的是哪套编排。
可复制模板：先写“任务契约”，再补“框架适配”
下面这段可以直接抄。它适合内容生成、研究摘要、结构化输出这类任务。
text你现在的任务是：产出【目标产物】。
请先遵守下面的任务契约：
1. 输出格式：只输出【Markdown / JSON / 纯文本】。
2. 必含结构：包含【标题 / 小节 / FAQ / 指定字段】。
3. 禁止输出：不要输出工具调用标签、不要反问编排框架、不要暴露思维链。
4. 信息不足时：先按已知信息完成主体，无法确认的地方标注“⚠️ 待确认”。
5. 如果任务本身不要求框架代码，就不要询问 LangChain / AutoGen / CrewAI 等实现细节。
如果还需要框架适配，我会在后续单独补充“运行环境备注”。
然后，真的需要接框架时，再补第二段。
text运行环境备注（可选）：
- 编排系统：LangChain / AutoGen / CrewAI / 自研
- 工具调用方式：由上层执行，模型只返回结构化文本
- 输出校验：由解析器检查 JSON / frontmatter / Markdown
- 失败策略：超时则返回部分结果，不中断主任务
这两层分开，后面迁移框架会轻松很多。
什么时候必须先问框架，什么时候根本不用问？
这个边界很多人确实没想清楚。我给你一个最省脑子的判断表。
| 场景 | 要不要先问框架 | 原因 |
|---|---|---|
| 写文章、摘要、FAQ、报告 | 不用 | 交付物是文本，本质与框架弱相关 |
| 输出 JSON 给工作流下游消费 | 通常不用 | 先定字段和校验规则更重要 |
| 设计 Agent 协作流程 | 可以后问 | 先画角色分工，再选实现方式 |
| 写 LangChain/AutoGen/CrewAI 的具体代码 | 要问 | 语法、对象模型、执行方式都不同 |
| 调试工具调用失败 | 要问 | 问题就在运行时适配层 |
一句话版判断标准：你是在交付“内容”，还是在交付“接线图”？
前者先定格式，后者先问框架。
这里还有个特别现实的点：很多团队嘴上说自己在做“多智能体系统”，真正上线的那部分其实很朴素——一个主流程，配几个工具调用，一个结构化输出校验器。真到这一步，框架名的重要性可能还不如“字段名能不能稳定对上”。
我不是说框架选择不重要。只是它经常被拿来提前占据注意力，像会议里那个最先开口的人。声音大，不等于最该先解决。
如果你现在就在做内容工作流，最该补哪一层？
先补 输出契约。
尤其是下面这三类场景：
- AI 写博客、写周报、写产品说明
- AI 回结构化数据给工作流节点
- AI 作为子助手给上游系统供稿
你最先该补的不是“支持哪套 Agent 框架”，而是下面这张清单：
- 最终产物长什么样
- 哪些字段绝不能漏
- 哪些内容禁止编
- 信息不足时允许怎样降级
- 谁来验收结果是否合格
把这五条写明白后，你会明显感觉到：模型少废话了，返工也少了。
有些本来看起来像“模型不够聪明”的问题，最后其实只是因为你没告诉它，交稿时到底算不算完成。
你可以从一个很小的动作开始
下次再看到 AI 第一轮就问“LangChain 还是 CrewAI”，你先别急着回答框架。先把问题拧回到交付上：“你先按无框架假设交付一个可用结果；哪里需要运行时支持，再列出缺口。”
然后观察一件事：它会不会自动把“框架”从主线退到备注里？
如果它退得下去，你的提示词大概率会更稳。
如果它退不下去，那可能不是框架选错了，而是你们的“输出契约”还不够硬——你觉得你写清了，但我不敢保证模型也同样理解了。你觉得你现在的任务，最容易被误解的那条交付标准是什么？
FAQ
Q: 我做的是纯内容生成，也要关心多智能体编排吗？
A: 要，但先关心输出契约。大多数内容任务先把格式、禁区、降级规则写清，编排框架可以后置。
Q: 那 LangChain、AutoGen、CrewAI 该怎么选？
A: 如果你还在验证任务本身能不能跑通，先别急着选。先做框架无关的最小流程，再看你更需要状态流转、角色协作，还是轻量自研。
Q: 什么时候一定要把框架写进提示词？
A: 当你要交付的是某个框架的具体代码、工具注册方式或调试方案时，必须写；只是要文本结果时，通常不用先写。