AI 技术栈的收敛与分化

一个判据与它的机制

做 AI 应用，最让人困惑的时刻不是某个技术太难，而是选型时碰到的一种反差。

有的技术层，整个行业只有一个答案。工具调用？MCP。结构化输出？JSON Schema 约束解码。这些层无需选择，也没人纠结——答案就在那里，所有人都用同一个。

有的技术层，所有人都在给出不同答案，而且每个答案在自己场景下都是对的。记忆层是个缩影——让 AI"记住用户"这件事，至少八种截然不同的方案：OpenAI 让 ChatGPT 在后台自动记，Anthropic 把记忆存成 Markdown 文件，Mem0 用向量检索被动提取，Zep 用时序图谱追踪"这件事现在还成不成立"。八种方案对应八种关于"记忆是什么"的回答。没人能裁定哪个对——因为哪个都对，在它自己的定义下。

这个反差不是偶然的，也跟"技术不成熟"没关系。工具调用在 API 格式还没统一时就已经收敛了，记忆却越做越分化。

本文给出一个判据——"这层能不能写成 spec"——再给出一个动态命题——收敛与分化互为因果——回答技术栈为什么不会静止。 判据是切片，互生是螺旋。判据背后六种不同性质的力量向上抽象为三类机制；判据与互生命题合起来，形成静态力学+动力学的双层框架。用这个框架可解释每一个域为什么收敛/分化，以及技术栈接下来的演化。

本文是作者 AI 产业认知三部曲的第三篇。《AI 行业的五极生态》讲行业结构——谁在场上，谁和谁博弈；《AI 时代的生态运营》讲运营规律——生态怎么转，谁锁定谁；本文讲技术栈的底层规律——为什么有些层注定趋同，有些层注定分化。三篇是从行业、运营、技术三个切面看 AI，尺度不同，同一套判断方法。

本文判断截至 2026 年 7 月，基于公开技术文档与各厂家产品的实际行为；结构判断为推导，与引用的产品立场无关。

一、一个判据——能不能写成 spec

先把判据说清楚。

一个技术域能不能收敛，取决于这层能不能被写成一个 spec——让两个独立团队按 spec 实现后能互通的、可被独立验证的规格说明。

能写成 spec → 有正确答案 → 收敛。写不成 spec → 没有正确答案 → 分化。不想写 spec → 分化，但可被网络效应克服后收敛。

具体而言，三种情况：

1. 能写成 spec：这层的接口语义清晰、行为可以被客观验证。工具调用的 spec 写得出来（名字+描述+入参 schema+执行体），所以一旦事实标准成型，全行业跟进。
2. 写不成 spec：这层的"对错"依赖场景偏好或产品哲学。"该记什么""什么叫好的回答""Agent 该有多自主"——这些问题写不成不依赖场景的规则。所以记忆、评测、Agent 规划这些域会持续分化。
3. 不想写 spec：厂商有动力保持差异化（壁垒、锁定）。但这种阻力可以被网络效应压倒——MCP 就是证据。

判据有一个方便的自检方法：面对一个技术域，问"这层的行为能不能被独立验证"。 能——工程契约，会收敛。不能——要么是哲学问题（永远不收敛），要么是理论未成熟（暂时不收敛）。

判据不预测"谁赢"，它预测"哪层会稳定"。无需知道记忆最后谁做得最好，只需知道记忆层写不成 spec，所以它不会稳定，会持续分化。理解为什么分化，比知道"谁赢"更有用。

二、判据背后的机制——三类力量

上一部分给出了判据（能不能写 spec），这一部分解释为什么有的层能写、有的层不能。

AI 技术栈的收敛/分化由六种不同性质的力量决定。但它们不是平铺的六个变量——它们汇入同一个出口："能不能写 spec"。按这个出口，六力向上抽象为三类机制：

第一类：推动 spec 存在的力

这三种力让一个域能写出 spec，并且能在行业中锁定这个 spec。

物理约束——所有人面对同样的物理定律。显存有上限、注意力有 O(n²) 复杂度、信息论有形式化边界。当物理约束定义了"必须怎么做"，解法必然趋同，spec 有自然基础。结构化输出是个例子——JSON Schema 可转为上下文无关文法，解码时用 grammar 约束采样空间，这是数学，不是意见。

工程经济学——N×M 集成负担越重，标准化的动力越强。M 个应用×N 个工具，没有标准就得写 M×N 个集成。这个负担是显性的、可量化的、让所有人痛苦的。当标准化的收益压倒差异化的收益，spec 就会被推出来。工具调用（MCP）是教科书案例——N×M 负担让所有厂商都有动力向同一 spec 靠拢。

网络效应——越多人用同一个 spec，它就越有价值。工具供应商更愿意为广泛采用的协议写集成；应用开发者更愿意支持有丰富生态的协议。一旦跨过临界点，正反馈不可逆。MCP 月 SDK 下载量从 0 到 1.1 亿只用了十六个月——不是因为委员会投票，是因为网络效应。

第二类：阻止 spec 存在的力

这两种力让一个域永远写不出稳定的 spec。

认知哲学——问题本身没有客观答案。"记忆是什么""什么叫好的回答""Agent 该由谁规划"——这些不是工程问题，是"该怎么认知"的问题。人类认知科学里有三四种记忆模型并存了半个世纪，凭什么 AI 记忆就该有一种正确答案？这类问题写不成 spec，因为 spec 要求不依赖场景的规则，而认知问题的答案天生依赖价值判断。

对抗性动态——每出现一个 spec，攻击者就会找到绕过的方法。安全的本质是军备竞赛：一旦定义了 prompt injection 的检测规则，攻击者换个写法就绕过；一旦发布 benchmark，模型就在训练集里污染它。对抗性动态让 spec 永远在变——不是技术不成熟，而是对手也在进化。传统网络安全里的 WAF 规则二十年了还在演化，AI 安全只会更快。

第三类：可以被克服的阻力

商业博弈——厂商有动力保持差异化（壁垒、用户粘性），所以"不想写 spec"。但商业博弈和其他阻力有本质区别：它可被网络效应压倒。MCP 的收敛过程证明了这一点——Anthropic 开源+捐赠给 Linux Foundation，消除"厂商锁定"顾虑后，竞争对手也选择跟进，因为不跟进的生态成本高于差异化收益。

关键判断：商业博弈是可克服的，认知哲学和对抗性动态不是。 所以涉及"怎么通信"的域（商业博弈主导）最终会收敛，涉及"怎么认知"的域（认知哲学主导）不会，涉及"怎么对抗"的域（对抗性主导）永远不会。

时间因素：理论成熟度

上述三类力量之外，还有时间维度。理论不成熟时，即使问题是工程性的，暂时也写不出 spec。 等理论成熟后，工程问题会收敛。RAG 的检索算法层已经收敛（混合检索+reranker，可 benchmark 验证），但检索策略层还没收敛（chunk 怎么切、query 怎么改写），因为这部分还停留在经验阶段。理论成熟度是时间变量——它决定了"暂时分化"还是"永远分化"。

六种力——物理约束、工程经济学、网络效应、认知哲学、对抗性动态、商业博弈——加上时间因素，全部汇入一个出口：

能写 spec（物理+工程经济学+网络效应 > 商业博弈）→ 收敛
写不成 spec（认知哲学或对抗性动态主导）→ 分化或永不收敛
理论未成熟（暂时写不出）→ 暂时分化，成熟后可能收敛

向上抽象层的好处：无需记六个力，只需理解三类机制（推动/阻止/可克服）如何作用于一个判据（能不能写 spec）。然后面对任何一个技术域，问：这层的行为能不能被独立验证？阻碍收敛的是什么性质的力？这个力可克服吗？

三、收敛与分化的互生

判据回答了"某一层为什么收敛/分化"。但收敛与分化不是孤立的静态分类——它们互为因果，不静止：收敛锁死表层契约，把不确定性推到相邻层显形；分化中工程部分会被技术进步解决、再度收敛，哲学部分不会。技术栈不会停在"有些层收敛有些层分化"，它在螺旋演化。下面三点是这个动态结构的表现。

收敛层暴露分化层。 工具调用收敛后，"工具调得好不好"就凸出来了——协议不统一时可以归咎于接口不兼容，协议统一后这套借口消失了，差异被推到评测层、记忆层、上下文层。收敛锁死表层契约，不确定性没有消解，被推到相邻的认知层显形。分化一直在那里，只是表层乱时难以分清哪个差异是协议问题、哪个是认知问题。表层稳定了，认知层的分化才看得清。

分化层制约收敛层的质量标准。 分化层拖不住契约收敛——工具调用的四元组不需要等评测层先收敛。但分化层拖得住"质量标准"的收敛。全行业同意工具调用长什么样，但全行业没同意怎么算"调得好"——因为"好"的标准在分化层，不在收敛层。契约收敛了，质量没收敛。

工程分化会收敛，哲学分化不会。 不是所有分化层都永远分化。判断一个分化层会不会收敛，看它背后的力量性质：工程不确定性（存储效率、检索精度、推理成本）可被技术进步解决，因为它们的效果可验证；哲学不确定性（该忠于事实还是偏好、Agent 该自主还是可控）不会被技术进步解决，因为它们不是技术问题，是"该怎么定义"的问题。可验证的会收敛，依赖价值判断的不会。

四、全栈逐域验证

用判据+机制解释 AI 技术栈的每一层。

排序逻辑：按收敛程度分为收敛域→半收敛域→分化域，子类内部按数据流（输入构造→信息注入→上下文组织→推理循环→多体协作→事后评估→横切防护）排列。

收敛域：spec 存在且被锁定

这些域的推动力（物理约束+工程经济学+网络效应）远大于阻力（商业博弈可被克服）。共同特征：接口语义清晰、N×M 负担重、网络效应强、行为可独立验证。实践方针：直接用标准，不造轮子。

域1：模型 API 格式

现状：高度收敛。OpenAI 的 Chat Completions API、Anthropic 的 Messages API、Google 的 GenerateContent API，三家的心智模型几乎一致——messages 数组（role+content）、tools 参数、stream 选项。DeepSeek、智谱、通义等后起厂商直接照搬了 OpenAI 格式。

为什么能写 spec：API 格式的差异化收益为零——没有用户因为"API 格式更优雅"而选择。但格式不一致的迁移成本是实打实的。商业博弈（不想写）被工程经济学（迁移成本）和网络效应（兼容生态）压倒。 这和 RESTful API、JDBC 的收敛逻辑一模一样。

实践参考：直接用事实标准或兼容层（LiteLLM、Portkey）。不要自己写适配层。

域2：工具调用（MCP）

现状：已收敛到 MCP。从 2023 年 OpenAI Plugins 的封闭试水，到 2024 年 Anthropic 发布 MCP 开放标准，到 2025 年三大厂商加入，到 2025 年底捐赠 Linux Foundation——不到三年完成收敛。2026 年中 MCP 月 SDK 下载量突破 1.1 亿，活跃公共服务器超 13000 个。

为什么能写 spec：教科书案例。spec 天然存在——工具的描述就是函数签名（name+description+parameters schema），这是软件工程最成熟的抽象。N×M 集成负担极重，网络效应极强，商业博弈（每家想做自己的协议）被彻底压倒。MCP 的收敛速度远超历史先例（React 十六个月达月下载 1 亿，MCP 用了同样时间），因为 N×M 负担在 AI 领域特别重。

实践参考：直接用 MCP。工具提供方写 MCP 服务器，AI 应用方支持 MCP 客户端。传输层和安全层（沙箱、认证、预算控制）还不完全成熟，生产部署需叠加防护。

域3：结构化输出

现状：高度收敛。JSON Schema 约束解码已成标配——OpenAI Structured Outputs、Anthropic tool_schema strict、Google response_schema、Outlines、xgrammar，原理一致：给定 JSON Schema 转上下文无关文法，解码时 grammar 约束采样空间。技术路径走完了一个完整收敛周期：Prompt 阶段（2023，格式不稳）→ 模型专训阶段（SFT 加入工具调用语料）→ 约束解码阶段（grammar 强制满足 schema）。

为什么能写 spec：底层是物理/数学约束——JSON Schema 可转换为 CFG，CFG 约束解码有成熟形式化解法（xgrammar、Outlines 都基于此原理），不是技术路线之争，是同一个数学问题的不同实现。上层是工程标准——JSON Schema 本身就是成熟标准。物理约束+工程标准双重推动，不存在商业博弈空间。

实践参考：直接用模型原生 Structured Outputs。不支持原生约束解码的模型用 Outlines 或 xgrammar 外挂。不要靠 prompt+正则获取结构化输出。

半收敛域：底层 spec 存在，上层 spec 不存在

这些域内部是分层的：底层方法论能写 spec（可 benchmark 验证），正在收敛；上层策略写不出 spec（依赖场景偏好），继续分化。实践方针：方法论用标准，策略按场景选。

域4：RAG/检索

现状：底层方法论趋同，按 RAG 流水线看每个阶段都有标配——离线索引（embedding + 向量库）、在线召回（vector + BM25 混合检索）、精排（cross-encoder rerank）。上层策略分化，同样是这条流水线的决策点没有统一最优解：索引阶段（分块方式：固定/语义/层级；索引结构：向量/图/树）、查询阶段（query 改写、检索策略：单次/多跳/递归）、架构层（是否 agentic）。

为什么半收敛：底层可 benchmark 验证，算法效果可量化，所以收敛（工程经济学推动）。上层策略的效果依赖文档类型、query 类型、模型特性，没有跨场景的通用指标，所以分化（经验/认知问题，理论未成熟）。物理约束（窗口有限）只限定"必须检索"，不指明"怎么检索最好"。

实践参考：方法论用标准——embedding 用主流模型、向量库用 Pgvector/Milvus/Qdrant、召回用 vector+BM25 混合、rerank 用 BGE-reranker 或 Cohere Rerank。策略按场景选——文档密集型用 LlamaIndex，对话+工具型用 LangChain/LangGraph，混合场景两者组合。务必加 eval（RAGAS 四指标持续监控）。

域5：评估

现状：方法论在收敛——LLM-as-judge 已成 2026 年事实标准（与人类判断一致率 80-90%，成本 1/500-1/5000），RAGAS 四指标（faithfulness/relevancy/precision/recall）成了 RAG 评估共识，三层架构（自动 benchmark→LLM-as-judge→人工抽检）是行业标配。评估目标在分化——客服 agent 看任务完成率，代码 agent 看 pass@1，RAG 看忠实度，安全看越狱率。"什么叫好"每个场景有自己的定义。而且评估面临对抗性问题——benchmark 污染、过拟合、饱和（MMLU 被打满到 92-94%）。

为什么半收敛+对抗性：方法论收敛因为可被独立验证（LLM-as-judge 的一致率可量化，工程经济学推动）。评估目标分化因为"什么叫好"是场景相关的哲学问题。对抗性动态进一步叠加——每出一个 benchmark 就被博弈绕过，需要持续更新。场景内收敛、跨场景分化。

实践参考：方法用标准——LLM-as-judge 用 DeepEval 或 RAGAS，三层架构是生产标配。目标按场景定——RAG 用 RAGAS 四指标，代码 agent 用 pass@1，安全用红队扫描。评估集定期更新防污染，接入 CI/CD 每次变更自动跑回归。

域6：Bad Case 诊断修复闭环

现状：2026 年开始从分化走向半收敛。底层状态机契约正在成型--pending -> diagnosed -> repaired -> verified -> resolved，每步带守卫条件与回归门；云厂商的 Agent 运行时服务 2026-06 把"failure insights -> root cause -> generate fixes -> prove they work"做成产品，是契约开始收敛的信号。上层诊断质量持续分化：诊断准不准、一个 bad case 的信号可不可信（规则驱动还是 LLM 驱动）、什么叫"修好了"，每个场景有自己的答案。

为什么半收敛：状态机能写 spec--修没修、验没验过可被独立验证，工程经济学推动收敛。诊断质量写不出 spec--"诊断准不准""信号可不可信""修好了没有"是认知哲学问题，依赖场景偏好；叠加对抗性，bad case 模式随业务演化，修过的 case 会再坏（回归）。状态机契约会收敛，诊断质量不会。这正是"收敛层暴露分化层"的活例证：契约一旦收敛，"诊断质量"这个分化层就显形了--同一套状态机，谁诊断得准、敢不敢自动修，差异全在这里。

实践参考：方法论用标准--状态机契约（diagnose -> repair -> verify -> resolved + 守卫条件：低置信度转人工、验证反证不可标 resolved、同 case 3 次进 pipeline 强制人工），LLM-as-judge 做验证，回归集防"修过的再坏"。策略按场景选--诊断深度、自动修复边界、人工门控阈值因场景而异。关键原则：区分信号可信度--规则驱动可自动修，LLM 驱动转人工，不在不可信信号上自动改系统。

域7：Skill

现状：2026 年中已进入生态化阶段。底层收敛——MCP 协议负责工具连接、SKILL.md 格式规范（Supabase 提出的开放标准：文件夹结构+自动发现+跨平台兼容）正在形成网络效应。上层分化——每个 Skill 定义的是"遇到什么场景、用什么工具、走什么流程、输出什么结果"，这是业务逻辑，因场景而异。SkillHub 上 Skill 超 5 万个，ClawHub 有 33000+。

为什么半收敛：底层能写 spec（MCP 协议+SKILL.md 格式，工程经济学+网络效应推动）。上层写不出 spec（业务逻辑各不相同，认知/经验问题）。和 RAG 同构——方法论收敛，策略分化。

实践参考：MCP+Skill 组合，MCP 负责连接，Skill 负责业务封装。优先官方 Skills（Supabase、Vercel、Stripe、Linear）。自建遵循 SKILL.md 开放标准。

分化域：spec 不存在或永无止境

这些域的阻力（认知哲学+对抗性动态+商业博弈）远大于推动力。共同特征：涉及"AI 该怎么认知/怎么决策/怎么对抗"，没有跨场景的客观答案。实践方针：必须做选择，且选择决定产品定位。

子类内部按数据流排序：Prompt 工程（输入构造）→ 记忆（信息注入）→ 上下文工程（上下文组织）→ Agent 规划（推理循环）→ 多 Agent（多体协作）→ 安全（横切防护）。

域8：Prompt 工程

现状：高度分化，且正在被"loop 工程"取代。2023 年的黄金时代——CoT、Few-shot、Role-play 等各种技巧层出不穷——已经过去。2025 年后的趋势是把结构从 prompt 外推到 loop 框架：ReAct 把"推理+行动"变成框架模式，Plan-and-Execute 把"先规划"变成显式规划层，Reflexion 把"自我反思"变成外层循环。Prompt 工程从"让模型变聪明的核心手段"降级为"基础配置"。

为什么写不出 spec：纯经验问题，无理论指导。为什么 "Let's think step by step" 有用？没有严格理论解释，只有经验观察。而且不同模型对同一 prompt 的反应不同——Claude 对 XML 标签敏感，GPT 对 markdown 敏感。模型相关性+经验性=写不出跨模型、跨场景的 spec。认知/经验问题主导，理论未成熟。 同时被结构性方案（loop 框架）替代——能外推的结构比 prompt 技巧更可靠。

实践参考：System prompt 精炼（角色+规则+输出格式），能外推的结构就外推。不要花三天调 prompt 解决幻觉——加 RAG 或 guardrail。按模型优化 prompt 格式。把 prompt 当配置管理——版本化、A/B 测试、回归测试。

域9：记忆

现状：高度分化，且在两个正交轴上同时分化。第一轴是本体论--"记什么"：OpenAI 黑箱自动记忆、Anthropic 文件即记忆、Cursor 分层规则+对话学习、Mem0 被动提取、Letta OS 式三层、Zep 时序图谱、LangMem 认知心理学三分法、Gemini 超大窗口绕过记忆，八种方案背后是八种"记忆是什么"的假设。第二轴是归属--"归谁、跨多大范围共享"：个人本地（CLAUDE.md）、个人多端同步、团队共享、云厂商托管的治理型记忆服务。两轴正交：本地分层记忆（如 Letta）与云托管分层记忆在本体论轴上同构（都借认知心理学），在归属轴上分道扬镳--前者 agent 自管理、记忆留本地，后者组织共享、记忆上云，只看一个轴区分不出两者。直到 2025 年才有 CoALA 框架尝试标准化术语，2026 年才有 LongMemEval 作为比较基准。

为什么写不出 spec：三层阻力叠加。

第一层是认知哲学。"记忆是什么"没有共识——是历史对话的子集？是提取出来的事实？是带时间戳的图谱？是认知心理学的三类知识？每个定义指向完全不同的实现。认知科学本身有多个记忆模型并存了半个多世纪，直接搬到 AI 上无定论。

第二层是商业博弈，在归属轴上尤其突出。记忆直接决定用户体验、粘性与数据主权。OpenAI 的黑箱自动记忆让 ChatGPT"越用越懂你"是核心壁垒；Anthropic 的透明文件记忆吸引需要可控性的专业用户；云厂商把记忆做成全托管服务，记忆越深迁移成本越高，是云锁定的强化。标准化记忆等于放弃差异化，厂商无动力。"记忆归谁"写不出 spec--它是治理/合规问题，依赖 jurisdiction 和组织边界，不是工程问题。

第三层——特殊的是——这层还叠加了物理约束。attention 远距退化（NoLiMa ICML 2025 证明 13 个模型中 11 个在 32K 时跌破基线 50%，退化归因于 attention 机制本身而非 RoPE）、信息过挤压定理、U 形衰减初始化即有——这些是物理极限，不是哲学分歧。精确召回有形式化上限。这意味着记忆层有两个性质的阻力：哲学问题（"该记什么"没有正确答案）+ 物理上限（精确召回有形式化边界）。

这引出一个更精确的判断：记忆层"该记什么"是哲学问题→永不收敛；"存储/检索效率"是工程问题→会收敛；"物理上限内如何最优"是未解决的工程问题→等理论成熟后可能收敛。 归属轴同理半收敛：跨端同步协议（记忆跨设备一致性）是工程问题→会收敛；治理边界（谁能看谁的记忆、跨人共享到什么程度）是合规/主权问题→不会收敛。所以记忆层未来不会是"统一"，而是"底层工程逐渐收敛，上层认知永远分化"。

实践参考：记忆是最需要按场景选的域，且要在两个轴上各做一次选择。

第一步定本体论（记什么）：

• 通用消费级助手 → 黑箱自动记忆（Mem0 式），用户不想管
• 专业/企业级应用 → 显式文件记忆（CLAUDE.md 式），用户要可控可审计
• 长期自主 agent → OS 式分层记忆（Letta 式），AI 自管理
• 事实变迁场景（CRM、客服）→ 时序图谱（Zep 式），追踪"现在还成不成立"

第二步定归属（归谁、跨多大范围共享）：

• 单人单机 → 本地文件，记忆绑设备
• 单人多终端 → 同步协议或云托管，记忆跟人
• 团队共享 → 命名空间隔离的共享记忆（云托管式），记忆跟组织，需治理边界

关键原则：先想清楚"应用需要什么类型的记忆"，再想"这份记忆归谁、要跨多大范围共享"。不要默认"记忆=向量库"，也不要默认"记忆绑单机"。

域10：上下文工程

现状：高度分化，且被严重低估。上下文工程是"怎么往窗口里塞东西"——塞什么、塞多少、按什么顺序、怎么压缩。和记忆不等同：记忆是跨会话持久化，上下文工程是单次推理内的信息组织。没有理论指导，全靠经验。（注：本文取上下文工程的狭义定义，聚焦窗口内的信息组织与编排。业界更宽的定义——如 Anthropic 2025 年 9 月 Effective context engineering for AI agents 及学术综述 arXiv:2507.13334——将 RAG/检索也纳入上下文工程范畴。本文为分析收敛/分化状态将两者分开讨论：RAG 底层方法论已半收敛，上下文工程全层分化，收敛状态不同所以分列。）

为什么写不出 spec：物理约束只给了硬边界（窗口有限、O(n²)复杂度），不指明怎么在边界内最优分配。"怎么组织信息让模型理解最好"依赖模型的"认知方式"——Claude 对 XML 标签敏感，GPT 对 markdown 结构敏感，Gemini 注意力分布不同。模型相关性+经验性 = 写不出跨模型 spec。物理约束是推动力（给边界），但"边界内最优"是认知/经验问题（没有答案）。

实践参考：分层组织（System prompt→工具描述→检索结果→Few-shot→当前对话）。用结构化标签区分信息块。压缩而非截断历史对话。按需加载（Cursor Rules 四种触发模式是好范例）。A/B 测试不同组织方式。

域11：Agent 规划/编排

现状：高度分化。至少六种规划范式并存——ReAct（推理+行动交替）、Plan-and-Execute（先规划再执行）、Reflexion（自我反思迭代）、Tree of Thoughts（多路径搜索+回溯）、CodeAct（action 压缩为代码）、Hierarchical/Subagent（主 loop 分发子任务）。框架格局：LangGraph（显式状态图模式）和 CrewAI（角色团队模式，日执行量 1200 万）是两大主流。AutoGen 已于 2026 年进入维护模式，合并为 Microsoft Agent Framework。2025-2026 年演化主线是"从 prompt 外推到 loop"——loop 越来越厚，prompt 越来越薄。

为什么写不出 spec：认知哲学是首要根因。 "智能的结构是什么""Agent 该怎么思考"——人类认知科学里未解决的基本问题。ReAct 模仿"边想边做"，Plan-and-Execute 模仿"先想好再做"，Reflexion 模仿"做完反思"，ToT 模仿"多方探索选最优"。每种范式后是对"人类怎么解决问题"的不同假设——人类自己用哪种策略取决于问题类型，agent 也必然如此。

三派（模型派/框架派/分离派）连"谁该规划"都没共识——这不是三种实现，是三种产品哲学。

执行框架会收敛（工程层，可写 spec），"该由谁规划"不会收敛（哲学层，写不出 spec）。 商业博弈叠加——Agent 框架是平台级机会，谁定义编排谁占据操作系统层。

实践参考：

• 简单工具调用 → ReAct
• 复杂多步任务 → Plan-and-Execute
• 需要自我纠错 → Reflexion
• 需要探索最优解 → Tree of Thoughts
• 长任务、需上下文隔离 → Subagent/Hierarchical
• 框架选型：流程清晰+快速交付 → CrewAI；显式状态管理+长任务 → LangGraph；.NET/Azure 生态 → MAF（AutoGen 继任者）；类型安全优先 → PydanticAI

关键原则：不要一个范式通吃所有场景。⚠️ 不建议新项目使用 AutoGen——已进入维护模式。

域12：多 Agent 协作

现状：高度分化，比单体 Agent 更早期。协作模式至少有 Sequential（串行）、Hierarchical（层级委派）、GroupChat（群聊协商）、Debate（对抗辩论）、Market-based（竞标分配）。通信协议层面 A2A（Google 2025 年 4 月发布）已被主流框架采纳，但协议采纳≠协作模式收敛。状态管理层面 CrewAI 用隐式记忆、LangGraph 用显式状态通道、MAF 用消息历史——三种完全不同的"agent 间怎么共享信息"的哲学。

为什么写不出 spec：同 Agent 规划（认知哲学+理论不成熟+商业博弈），但更早期。多 Agent 的本质是分布式认知——对应组织理论和分布式系统理论的交叉地带，两个领域本身都没有唯一解。人类组织架构都有矩阵式、职能式、事业部式之分，agent 协作必然长期分化。

通信协议会收敛（工程层），协作模式不会（哲学层）。

实践参考：能单体就别多 Agent——协调成本（通信开销、状态同步、错误传播）往往超过收益。3-5 个 agent 是舒适区。流水线型→ Sequential/CrewAI，需讨论→ GroupChat/MAF，需层级委派→ Hierarchical/Subagent。

域13：安全

现状：高度分化，且永远不会收敛。安全工具栈至少有六类：Future AGI Guardrails、NeMo Guardrails、GuardrailsAI、Lakera Guard、Protect AI LLM Guard、Microsoft Presidio。红队工具：Garak（LLM 的"Nmap"）、PyRIT、DeepTeam。2025 年 MITRE ATLAS 框架新增 14 种 AI 特有攻击技术，56% 的生产 LLM 可被 prompt 注入攻破。

为什么永远写不出 spec：对抗性动态是首要根因。 安全是军备竞赛——每出一个防御标准，攻击者就找绕过方法；每发现一种攻击，防御方就加规则。传统网络安全 WAF/IDS 二十年了还在演化，AI 安全更快——因为攻击面是自然语言，任何输入字符串都能操纵模型逻辑，比传统网络攻击面更难界定。

认知哲学叠加："什么是安全"没有跨场景共识——不输出有害内容？不执行未授权操作？不泄露敏感信息？不被操纵？不同定义指向不同策略。合规叠加：不同行业/地区合规要求不同（医疗 HIPAA、金融 SOX、欧盟 AI Act），策略必然碎片化。

实践参考：分层防御——输入层（Lakera/NeMo 检测注入）+ 输出层（GuardrailsAI 验证结构+PII 脱敏）+ 工具层（最小权限，关键操作要确认 token）+ RAG 层（检索结果过 guardrail）。不要靠 prompt 做安全（4 分钟就能绕过）。持续红队（Garak/PyRIT 定期扫描）。Guardrail 挂了要有 circuit breaker 和 fail-safe 策略。

五、选型逻辑

基于以上的判据+机制+验证，选型逻辑总结为三条原则。

原则一：收敛域直接用 spec，不造轮子

模型 API 格式、工具调用（MCP）、结构化输出——这三个域的 spec 存在且被锁定。在这些域花时间自研，是纯粹的机会成本浪费。精力应该花在分化域。

原则二：半收敛域方法论用标准，策略按场景选

RAG、评估、Skill 属于这一类。底层方法（混合检索、LLM-as-judge、MCP+SKILL.md）用标准方案。上层策略（分块方式、评估目标、业务逻辑）按具体场景定。这里的选型错误通常是"用错策略"而非"用错工具"。

原则三：分化域做选择，且选择决定产品定位

Prompt 工程、记忆、上下文工程、Agent 规划、多 Agent、安全——这些域的选型不是技术问题，是产品定位问题：

• 选黑箱自动记忆还是显式文件记忆 → 决定做的是"消费级傻瓜助手"还是"专业级可控工具"
• 选记忆绑单机还是跨终端/团队共享 → 决定做的是"个人工具"还是"组织级可治理服务"
• 选 ReAct 还是 Plan-and-Execute → 决定 agent 适合"实时交互"还是"复杂自动化"
• 选 CrewAI 还是 LangGraph → 决定多 agent 是"项目管理器"还是"状态机"
• 安全策略严格还是宽松 → 决定面向"受监管行业"还是"通用消费市场"

在这些域，没有最优解，只有最适合具体场景的解。选型前需想清楚产品是什么。

快速选型清单

结语

AI 技术栈的分化和收敛不是随机的，它背后有一个清晰的力学结构。但这个结构不需要六个变量来描述。向上抽象一层，它们汇入一个判据：

这层能不能写成 spec？

• 能（物理+工程经济学+网络效应 > 商业博弈）→ 直接用标准
• 一半能一半不能（底层可验证，上层依赖场景）→ 方法论用标准，策略按场景选
• 不能（认知哲学或对抗性主导）→ 做选择，选择决定产品定位
• 暂时不能（理论未成熟）→ 等，但要区分"暂时不能"和"永远不能"

但判据是切片，不是全貌。收敛与分化互为因果：收敛锁死表层契约，把不确定性推到相邻层显形；分化中工程部分会被技术进步解决、再度收敛，哲学部分不会。技术栈不会停在"有些层收敛有些层分化"，它在螺旋演化——判据定位此刻，互生指向接下来。

落地时最容易犯的错误，是在收敛域花时间自研（浪费），在分化域期待标准答案（失望）。正确的做法是：接受"有的域注定分化"这个现实，理解每个分化域分化的机制（是哲学问题还是物理约束还是对抗性），然后根据产品定位做选择。

没有"最优 AI 技术栈"，只有最适合具体场景的 AI 技术栈。而要做出适合的选择，所需的不只是"哪个工具最好"——更要理解 "为什么这层收敛/分化、阻力是什么性质的、可不可克服"。这就是本文的认知底座。

《AI 行业的五极生态》讲行业结构，《AI 时代的生态运营》讲运营规律，本文讲技术栈规律。三篇是从行业、运营、技术三个切面看 AI：谁在场上、生态怎么转、技术栈为什么有些层稳有些层乱。同一个判断方法——找结构性位置，看有没有正确答案。

收敛层决定能否进场，分化层决定能走多远。判据定位此刻，互生指向接下来。

附录：各技术域速查表

判断逻辑：一个判据（能不能写 spec）→ 三类机制（推动/阻止/可克服）→ 逐域验证 → 选型。子类内部按数据流排序。

本报告基于 2026 年 7 月公开资料整理。技术栈演化迅速，部分判断为基于框架的推导，已标注。