Compound Engineering：当 AI 工程从"模型调优"走向"系统组合"

2024 年，Berkeley AI Research 的文章 The Shift from Models to Compound AI Systems 把一个已经在工程现场发生的变化命名了：AI 应用的能力不再只来自单个模型，而越来越来自多个组件的组合。

模型仍然重要。但在知识更新、工具调用、权限控制、成本预算、延迟约束和可审计性面前，单个模型很难独自承担完整系统的责任。检索器（Retriever）、路由器、工具、工作流、验证器、监控和降级策略开始进入同一个架构图。围绕这种组合方式形成的工程实践，可以称为 Compound Engineering。

先把定义压实

Compound AI System，通常译作复合 AI 系统，指的是由多个相互作用的组件共同完成 AI 任务的系统。这些组件可以包括一次或多次模型调用、检索器、数据库、外部 API、代码执行器、专用模型、规则引擎、评估器和人工审核节点。

BAIR 对这个转向的判断很直接：不少 AI 任务的性能提升，已经不只依赖更大的模型，而依赖围绕模型搭建的系统。Databricks 后续也把复合 AI 系统描述为由模型、工具、检索、代理等组件构成的系统，并把 RAG 视为最典型的例子之一。

Compound Engineering 则是围绕复合 AI 系统的工程学科。它把提示词、Agent、工具和数据源放到同一个工程问题里，重点回答这些问题：

哪些能力该交给模型，哪些能力该交给检索、工具或规则？
任务应当按固定工作流执行，还是交给模型动态规划？
系统如何在准确率、延迟、成本和可用性之间取舍？
每个组件的输入输出如何定义、记录、评估和回放？
工具权限、数据边界、失败重试和降级路径如何设计？

一个压缩版定义是：

Compound Engineering 是设计、连接、评估和运营复合 AI 系统的工程方法。它把模型放在可连接、可替换、可评估的组件位置上。

为什么单体模型不够

大模型的通用能力提升了 AI 应用的天花板，但生产系统面对的是另一组约束。

知识需要运行时更新

模型参数里的知识天然滞后。企业知识库、产品价格、内部流程、代码仓库、数据库状态都在持续变化。把这些信息重新训练进模型既慢又贵，也很难通过权限审计。

RAG 的价值正在于此：把知识更新从训练阶段移到运行阶段。模型负责理解和生成，检索器负责从可信数据源取回证据。系统能力不再完全绑定在模型参数里。

行动需要工具和权限

许多任务不只是回答问题，还要执行动作：查数据库、改配置、发请求、跑代码、创建工单、更新文档、触发部署。模型本身不会天然知道哪些动作允许执行，也不会自动具备幂等、回滚、审计和权限隔离。

工具调用把 AI 从文本系统带到行动系统，同时也把权限、身份、审计和安全问题带进架构。Compound Engineering 必须把工具边界当成一等公民。

成本和延迟需要预算

所有请求都交给最强模型，架构最简单，但成本和延迟很快失控。所有请求都交给便宜模型，体验和可靠性又会下降。实际系统通常需要路由：简单任务走小模型或规则，复杂任务升级到强模型，关键任务再加验证器或人工审核。

Stanford 的 FrugalGPT 研究给出了一个清晰例子：通过提示适配、模型近似和模型级联，系统可以在接近 GPT-4 的表现下把成本最多降低 98%，也可以在同等成本下提升准确率。这个结果来自模型调用策略与级联路由，而非单个模型本身。

可信度需要可观测和可回放

生产环境里的问题通常不是“模型回答错了”这么简单。错误可能来自检索召回不足、重排序失误、上下文拼接污染、工具返回异常、路由策略错误、提示词版本变更、权限配置过宽，或者多个组件之间的状态不一致。

单体模型把许多因果链压进黑盒。复合系统把链路拆开，带来的复杂度更高，但也给了工程团队记录、回放、归因和修复的入口。

一个最小架构图

复合 AI 系统不一定复杂。最小形态可以像这样：

User Request
    |
    v
Intent / Policy Layer
    |
    v
Planner or Router
    |
    +--> Model
    +--> Retriever
    +--> Tool / API
    +--> Verifier
    |
    v
Response / Action
    |
    v
Trace / Eval / Feedback

这张图里，模型只是路径上的一个节点。系统能力来自组件之间的分工：

层次	责任	常见实现
意图与策略层	判断任务类型、风险等级、权限边界	分类器、规则、策略引擎
规划与路由层	决定调用哪些组件以及调用顺序	工作流、Router、Planner、Agent
模型层	理解、推理、生成、转换	通用大模型、领域模型、小模型
数据与上下文层	提供事实、记忆和业务状态	RAG、数据库、向量库、缓存
工具层	执行可审计动作	API、代码沙箱、浏览器、内部系统
验证层	检查答案、动作和证据	规则、评估模型、测试、人工审核
观测层	记录链路、指标和错误	Trace、日志、成本统计、回放系统

Compound Engineering 的第一步，通常是先把这些责任边界画清楚，再考虑框架选型。

六种可迁移的架构模式

不同系统会长出不同形态，但已经有几类模式反复出现。它们比具体框架更值得记住。

RAG：把知识放在模型外部

1	`Question -> Retrieve -> Rerank -> Compose Context -> Generate -> Cite / Verify`

RAG 是最常见的复合 AI 系统。它的目标是把可信来源带进回答过程，而非要求模型把知识全部记进参数。

RAG 的工程难点通常不在“接一个向量库”：

文档如何切分，才能既保留语义又便于召回？
查询是否需要改写、扩展或分解？
召回结果是否需要混合关键词检索、向量检索和结构化查询？
重排序模型如何选择，阈值如何调？
没有足够证据时，系统应该拒答、追问，还是升级到人工？
答案里的引用如何回到原始文档片段，而不是引用一个中间摘要？

模式提炼：RAG 把知识、证据和生成分离。检索质量、证据边界和拒答策略，往往比提示词更决定可靠性。

Router / Cascade：按任务难度分配预算

1	`Request -> Classify Difficulty -> Cheap Path -> Confidence Check -> Expensive Path`

路由和级联模式解决的是成本质量取舍。简单任务不必动用最强模型，复杂任务也不该被便宜路径拖垮。

FrugalGPT 的启发在于，系统可以先尝试成本更低的模型或提示策略，再根据置信度、分歧度、验证结果决定是否升级。这个策略适合客服、分类、抽取、摘要、常见问答等高并发场景。

一个实用级联通常会包含：

任务分类：区分低风险、高风险、复杂推理、需要外部知识的请求。
置信度估计：用模型自评、判别器、规则或多模型一致性评估。
升级条件：明确什么时候升级到更强模型、更多上下文或人工审核。
预算上限：限制最多调用几次、最多消耗多少 token、最多等待多久。
质量回放：定期抽样检查便宜路径是否吞掉了难题。

模式提炼：模型选择不应写死在业务代码里。把成本、延迟和风险变成路由策略，系统才有优化空间。

Prompt Chaining / Workflow：把复杂任务拆成稳定步骤

1	`Input -> Step 1 -> Checkpoint -> Step 2 -> Checkpoint -> Step 3 -> Output`

Anthropic 在《Building effective agents》中把 workflow 和 agent 区分得很清楚：workflow 是由代码预先定义路径的系统，agent 则由模型动态决定过程和工具使用。

很多业务任务并不需要完全自主的 Agent。合同审阅、报告生成、数据清洗、投放诊断、代码迁移，都可以拆成稳定步骤：读取材料、抽取结构、生成草稿、校验约束、输出结果。

固定工作流的优点是可控：

每一步输入输出清晰。
中间结果可以缓存和回放。
错误更容易定位。
权限边界更容易收紧。
评估集可以按步骤拆开。

模式提炼：能用 workflow 解决的任务，不必急着上 autonomous agent。先把路径写清楚，再把需要判断的节点交给模型。

Orchestrator-Workers：动态拆解复杂任务

Task -> Orchestrator -> Worker A
                   +--> Worker B
                   +--> Worker C
                   -> Synthesis / Review

当任务结构难以提前写死时，编排器加工作者的模式更合适。Anthropic 的多智能体研究系统采用了类似结构：一个 lead agent 负责规划和协调，多个 subagent 并行探索不同方向，最后汇总结果。

这种模式适合开放式研究、复杂代码库排查、多源材料综合、跨系统诊断等任务。优势是覆盖面和并行度，代价是协调复杂度、状态管理和错误传播。

工程上最容易出问题的地方包括：

子任务边界模糊，多个工作者重复探索同一块。
输出格式不稳定，汇总器难以比较结果。
子代理拿不到必要上下文，或者拿到过多无关上下文。
异步执行带来状态同步和失败恢复问题。
总调用量快速膨胀，成本不可预测。

模式提炼：多 Agent 的价值取决于边界。每个工作者应当有明确目标、输入、禁止事项和交付格式。

Generate-Filter-Verify：大量生成，再严格筛选

1	`Problem -> Generate Candidates -> Filter -> Rank -> Test / Verify -> Select`

DeepMind 的 AlphaCode 2 是这个模式的代表。它把生成从单次回答改为候选搜索，再通过过滤、聚类、评分和测试筛选出更好的解法。技术报告显示，AlphaCode 2 在模拟 Codeforces 评测中，10 次提交内解决了 43% 的问题，约达到参赛者第 85 百分位。

这种模式适合答案空间很大、验证相对明确的任务：

代码生成：候选程序可以通过测试验证。
数学推导：候选步骤可以被证明器或规则检查。
查询改写：候选查询可以用召回质量评估。
设计方案：候选方案可以用约束和评分器筛选。

模式提炼：当生成比验证便宜时，不必强迫模型一次生成正确答案。把搜索、筛选和验证写进系统，通常比单轮提示更稳。

Neuro-Symbolic：神经生成加符号验证

1	`Neural Model -> Candidate Idea -> Symbolic Engine -> Proof / Rejection -> Next Idea`

AlphaGeometry 展示了神经模型和符号系统的互补性。神经语言模型提出几何构造建议，符号演绎引擎负责严格验证证明步骤。DeepMind 公布的结果显示，AlphaGeometry 在 30 道奥林匹克几何题中解决了 25 道，接近人类金牌选手水平。

后续 AlphaProof 和 AlphaGeometry 2 在 2024 年国际数学奥林匹克题目上取得 28/42 分，达到银牌上沿，距离金牌线只差 1 分。这里的重点不只是“模型更强”，而是生成、搜索、形式化验证和符号推理形成了闭环。

模式提炼：高可靠场景不能只相信自然语言解释。能形式化的部分，应当交给符号工具、类型系统、测试、证明器或规则引擎。

与 Prompt、Context、Harness Engineering 的关系

Compound Engineering 经常和 Prompt Engineering、Context Engineering、Harness Engineering 混在一起。它们确实相关，但不在同一个层面。

概念	主要问题	典型对象	失败时的症状
Prompt Engineering	如何给模型下指令	指令、格式、示例、约束	输出风格不稳、格式不稳、任务理解偏差
Context Engineering	如何组织运行时上下文	检索结果、记忆、工具返回、对话状态	信息缺失、上下文污染、证据不完整
Harness Engineering	如何承载执行生命周期	工具循环、沙箱、重试、评估、状态机	会跑但不可控，失败不可回放
Compound Engineering	如何组合多个组件完成任务	模型、检索、工具、路由、验证、观测	架构臃肿、成本失控、错误难归因

可以把四者放到同一个例子里：

Prompt Engineering 负责让模型按指定格式抽取合同条款。
Context Engineering 负责把相关合同、历史补充协议和公司政策放进上下文。
Harness Engineering 负责执行工具调用、保存中间结果、处理重试和回放。
Compound Engineering 负责决定系统是否需要检索器、条款分类模型、风险评分器、法务审核节点和成本路由。

它们不是替代关系。一个成熟 AI 系统通常同时需要四种能力，只是 Compound Engineering 站在更高的系统组合层。

Harness Engineering 和 Compound Engineering 的层级差异

区分两者的关键在于各自回答的问题层级不同。

Harness Engineering 处理的是执行层面的问题：工具调用失败后重试几次？中间状态存在哪里？执行链路怎么回放和调试？沙箱的资源配额怎么设？这些问题的共同特征是，它们发生在一个已经确定要存在的组件内部，或者组件与组件之间的执行框架里。

Compound Engineering 处理的是更靠前的架构问题：这个组件该不该存在？系统需要几个模型？检索器和规则引擎之间的分工边界在哪里？验证器应该用符号引擎还是再调一次模型？路由策略按成本分还是按风险等级分？这些决定塑造的是系统拓扑，而非单个节点的运行机制。

仍以合同审阅为例。Harness 层面关心的是：合同解析工具超时后的重试策略、中间抽取结果的缓存位置、工具调用链路的 trace 格式。Compound 层面关心的是：系统是否需要一个独立的条款分类模型、风险评分应该走规则引擎还是走模型打分、法务审核节点在什么风险等级下才触发、成本预算怎么在检索和生成两个阶段之间分配。前者可以在不改变系统拓扑的情况下优化，后者的每一个决定都可能增减组件或改变数据流向。

协议层正在成形

复合系统一旦走向生产，就会遇到接口碎片化问题。模型要接数据库、搜索、文件、代码仓库、浏览器、内部 SaaS、权限系统和其他 Agent。每个工具都手写一套适配层，维护成本会迅速上升。

2024 到 2026 年间，几个协议和约定开始变得重要。

协议或约定	主要目标	工程意义
MCP	连接模型应用与工具、数据源和外部系统	把工具集成从零散适配变成可复用接口
A2A	Agent 之间发现能力、交换任务和协作	为跨供应商、多 Agent 协作提供通信层
AGENTS.md	给代码仓库中的 Agent 提供项目级指令	把本地工程约束写进可继承的文本契约

Anthropic 在 2024 年发布 Model Context Protocol，目标是用一个开放标准连接 AI 系统与数据源。2025 年，Linux Foundation 宣布成立 Agentic AI Foundation，MCP、AGENTS.md、Codex CLI 等项目进入更中立的治理脉络。Google 在 2025 年提出 Agent2Agent，也就是 A2A，核心机制之一是用 Agent Card 描述 Agent 的能力和通信入口。

协议层的出现，不意味着安全问题自动消失。恰恰相反，标准化会让工具暴露面更清晰，也会把权限、工具投毒、提示注入、跨 Agent 信任和审计问题推到更显眼的位置。Compound Engineering 需要同时设计“怎么连上”和“连上以后哪些事绝对不能做”。

值得谨慎的是 ACP 这个缩写。2025 到 2026 年间，ACP 在不同组织和论文里有多种含义，不宜把它直接当作已经收敛的单一行业协议。讨论生产架构时，更稳妥的做法是先说明具体来源和语义，再判断是否适合采用。

案例：组合带来的能力跃迁

FrugalGPT：用级联降低推理成本

FrugalGPT 的结论有两个方向：一是通过级联等策略，在接近 GPT-4 表现时显著降低成本；二是在同等成本约束下，通过组合多个模型和提示策略提升准确率。

这类系统的价值不在某个模型本身，而在“何时使用哪个模型”的策略。对企业应用来说，这往往比盲目升级到更贵模型更可持续。

AlphaGeometry：让创造和验证分工

几何证明既需要创造性构造，也需要严格验证。AlphaGeometry 把这两件事拆开：神经模型负责提出可能有用的构造，符号引擎负责证明是否成立。

这种分工给高可靠 AI 一个重要启发：自然语言模型适合产生候选思路，但最终正确性可以交给形式化工具、测试系统或确定性规则。

AlphaCode 2：把生成变成搜索过程

AlphaCode 2 的竞赛表现来自一个复合流程：大量生成候选代码，过滤明显错误的答案，再通过评分、聚类和测试挑选提交。模型调用被放进搜索和验证系统，而非停留在一次性回答。

对工程场景的启发很直接：代码生成、SQL 生成、配置迁移、数据修复这类任务，只要验证手段相对明确，就应当把候选生成和验证系统配套设计。

Anthropic 多智能体研究系统：并行扩大探索面

Anthropic 公布的多智能体研究系统采用 lead agent 加 subagents 的结构。lead agent 规划问题，多个 subagent 并行研究不同方向，再由系统综合结果。

这个案例同时说明了多 Agent 的价值和成本。并行可以扩大探索面，但也会带来协调、边界、上下文分配、异步错误和成本控制问题。多 Agent 更适合作为开放任务、难以预设步骤、并行探索收益足够高时的架构选择。

企业蓝图：registries、streams、planners

近年的企业复合 AI 系统论文开始把架构抽象为更完整的蓝图：需要模型和工具注册表，需要支持异步数据流，需要 planner 在准确率、成本、延迟和可用性之间优化。

这个方向把 Compound Engineering 从“应用技巧”推向“平台工程”。当一个组织有多个业务线、多个模型、多个数据源和多个工具权限时，最重要的资产可能不再是某条 prompt，而是统一的组件注册、评估、观测和治理体系。

工程难点

复合系统的收益来自组合，风险也来自组合。

设计空间爆炸

单模型系统的主要变量是模型、提示词和上下文。复合系统还要选择检索策略、chunk 大小、路由模型、工具权限、并发方式、缓存策略、验证器、降级路径和监控指标。每多一个组件，就多一组组合关系。

因此，Compound Engineering 不适合靠直觉堆组件。它需要从任务、约束和评估出发，逐步增加复杂度。

端到端优化困难

单独优化一个组件，不一定提升系统整体表现。检索召回更多内容可能提高覆盖率，也可能污染上下文。更强的重排序模型可能提高准确率，也可能增加延迟。更复杂的 Agent 规划可能解决长任务，也可能放大错误传播。

复合系统的评估不能只看组件局部指标，还要看端到端任务结果。

错误归因变难

当回答错误时，原因可能来自多个环节：

用户意图分类错了。
路由选错模型。
检索没有召回关键文档。
上下文排序把噪声放在前面。
工具返回了过期数据。
验证器没有拦住错误。
汇总器误解了子任务结果。

没有 trace、span、输入输出快照和版本记录，复合系统会很快变成不可调试的黑箱。

安全面扩大

工具越多，攻击面越大。MCP、浏览器、数据库、代码执行器、文件系统和内部 SaaS 都可能成为风险入口。提示注入不再只是让模型说错话，还可能诱导系统调用错误工具、泄露上下文、越权访问或执行危险动作。

安全设计需要覆盖：

工具最小权限。
用户身份和工具身份隔离。
高风险动作的确认和审核。
外部内容和内部指令的隔离。
工具返回内容的可信度标记。
操作日志和事后审计。

评估集维护成本上升

复合系统需要评估的不只是最终答案，还包括中间决策：检索是否命中、路由是否合理、工具调用是否必要、引用是否准确、拒答是否正确、降级是否生效。

这意味着评估集要覆盖更多维度。没有持续评估，系统很难判断新模型、新索引、新提示词或新工具接入到底是提升还是退化。

实践原则

从最简单可验证路径开始

Anthropic 对 agentic systems 的建议很克制：从最简单方案开始，只有当评估证明需要时才增加复杂度。这个原则尤其适合复合系统。

一个合理顺序是：

单模型加清晰 prompt。
加入必要上下文和引用。
加入检索与拒答策略。
加入工具调用和权限控制。
加入路由、级联或缓存。
加入验证器和回放机制。
在任务结构确实开放时，再考虑多 Agent。

每一步都应当能用评估证明价值。

把评估放在架构之前

没有评估，架构讨论很容易变成审美。复合系统至少需要三类评估：

任务评估：最终答案或动作是否满足业务目标。
组件评估：检索、路由、工具、验证器各自表现如何。
运行评估：成本、延迟、失败率、重试率、降级率、人工介入率。

评估需要前置，因为它决定架构该不该变复杂。

明确固定工作流和动态 Agent 的边界

能写成固定流程的任务，优先写成 workflow。需要模型判断的节点，再把判断权交给模型。只有任务结构高度开放、步骤难以提前枚举、并行探索收益足够高时，才让 Agent 动态规划。

这个边界可以降低很多不必要的不可控性。

让每个组件可替换

复合系统的一个优势是组件可替换。要做到这一点，需要稳定接口：

输入输出用结构化 schema。
工具调用有明确错误码。
检索结果保留来源、分数和版本。
模型输出保留提示词版本、模型版本和参数。
评估器能在离线环境回放旧请求。

如果换一个模型就要改一串业务逻辑，系统仍然是另一种形式的单体。

把预算写进系统

成本和延迟不应只在账单出来后才被讨论。每个请求都可以带预算：

最多调用多少次模型。
最多检索多少文档。
最多执行多少工具。
最长等待多久。
失败时降级到什么答案。

预算会让系统在压力下保持可预测。

把失败路径设计成产品能力

复合系统不可能永远成功。可靠系统的差异在于失败时如何表现：

证据不足时明确拒答。
工具不可用时走只读或缓存路径。
模型分歧时升级验证器或人工审核。
高风险动作前暂停并解释原因。
超过预算时返回部分结果和下一步建议。

优雅降级比“永远自信”更重要。

选型速查

场景	优先模式	关键评估指标
企业知识问答	RAG	引用准确率、召回率、拒答准确率
高频低风险客服	Router / Cascade	成本、延迟、升级率、满意度
合同或报告生成	Workflow / Prompt Chaining	步骤正确率、格式合规率、人工修改量
开放式研究	Orchestrator-Workers	覆盖率、重复率、事实错误率、成本
代码生成	Generate-Filter-Verify	测试通过率、提交次数、回归率
数学、规则、合规	Neuro-Symbolic	可证明正确率、误拦率、漏拦率
多系统企业平台	Registry / Planner / Streams	组件复用率、可用性、治理覆盖率

一个判断框架

在引入新组件之前，可以先问六个问题：

这个组件解决的是准确率、成本、延迟、安全、可维护性，还是只是让架构看起来更先进？
它的输入输出能否被记录、回放和离线评估？
它失败时的默认行为是什么？
它是否扩大了权限和数据暴露面？
它能否被更简单的 workflow、规则或缓存替代？
它带来的收益是否超过新增的监控、测试、调试和运维成本？

只要这六个问题答不清，系统暂时不需要更多组件。

术语的现状：Compound Engineering 并没有出圈

“Compound AI Systems” 这个概念有明确来源。BAIR 在 2024 年 2 月发表 The Shift from Models to Compound AI Systems，Databricks 随后跟进使用，学术论文和企业架构讨论里也开始出现这个短语。作为对"AI 应用能力越来越来自多个组件的组合"这一现象的命名，它成立且有用。

但 “Compound Engineering” 作为一个工程学科的名称，行业里并没有广泛采纳。2025 到 2026 年间真正进入一线工程师日常词汇的是另外两个术语：Context Engineering 和 Harness Engineering。前者聚焦运行时上下文的组装——检索结果怎么排、记忆怎么裁剪、工具返回怎么塞进窗口，Andrej Karpathy 等人的推动让它迅速传播。后者聚焦 agentic 执行框架：工具循环、沙箱、重试、状态机、回放，随 Agent 工具链的成熟而被越来越多团队使用。

Compound Engineering 试图占据的那个"系统架构组合"层，在实践中被更具体的子领域名称吸收了。做检索组合的人说自己在做 RAG 架构，做多 Agent 的人说自己在做 multi-agent orchestration，做路由的人说自己在做 model routing。很少有工程师会说"我在做 Compound Engineering"。

这不意味着概念本身错了。四层关系表里的分层——Prompt、Context、Harness、Compound——作为思考框架仍然有用，尤其在团队需要对齐"我们到底在讨论哪个层面的问题"时。只是在工程社区的术语演化中，umbrella 词往往让位给更贴近手感的具体词。Compound AI Systems 作为现象描述留了下来，Compound Engineering 作为学科标签没有站稳。

结语

Compound Engineering 的重点，是把模型放回工程系统里：可连接、可替换、可评估、可审计、可降级。

单个模型决定了系统的能力底座，系统组合决定了这份能力能否稳定进入生产。AI 工程岗位会越来越要求理解检索、路由、工具权限、评估、观测、协议和平台治理。

当模型能力继续提升，复合系统不会消失。相反，模型越强，越需要好的工程结构来约束它、放大它，并把它接入真实业务。