基于组件化的工程（CBE）智能体

基于组件化的工程（CBE）智能体

亚信科技（中国）有限公司

摘要：当前Agent多为'任务执行者'，擅长单步工具调用却难以交付复杂项目。本文提出'组件化工程（CBE）Agent'范式，通过固定元模型（Component-Connection-Constraint）实现问题形式化建模与自动求解，跨越从单一任务到系统交付的能力断层。CBE结合知识工程与程序化工具调用，使Agent具备全局约束验证与自动重构能力，为Agent从'过程计费'转向'结果付费'奠定工程基础。

我们早已习惯了"提示词 + 大模型 + 工具调用"的 Agent 架构——用户提出需求，模型拆解步骤，调用 API 获取数据，返回结果。在演示场景中，这套流程表现得像个称职的助理：查询酒店、预订机票、检索攻略，样样在行。

但一旦面对真实世界的复杂性，这个"助理"立即暴露出其工具本质。它能完美执行单个指令，却无法交付一个可信赖的完整项目。想象一下，你让它规划一趟东京之旅：它可以分别订好酒店和机票，却无法保证酒店退房时间与航班起飞时间的逻辑合理性；无法在预算超支时自动降级酒店并重新匹配航班；更不能在台风导致航班取消时，自动重构整个行程链并重新预订可退款的替代方案。

问题在于：拥有的是"任务执行者"，却期望它成为"项目交付者"。 前者只需要调用工具，后者需要构建一个逻辑自洽、约束满足、可验证正确的系统。这之间的鸿沟，不是通过更好的提示词或更强的基础模型就能填平的——它需要的是工程化范式的根本升级。

可靠性与治理鸿沟。Gartner预测，到2027年，超过40%的代理型AI项目将被废弃 [1]。大型语言模型运行良好。问题在于他们周围的一切：身份管理、审计追踪、错误处理、合规性。

上述"任务执行者"与"项目交付者"之间的能力断层，并非 Agent 架构演进的起点，而是其发展过程中的阶段性困境。回顾两年前的工程实践，主流 Agent 遵循的是朴素的"提示词 + LLM + 工具调用"范式——即 ReAct（Reasoning-Acting）架构：模型在对话中生成推理轨迹（Thought），发起工具调用（Action），系统执行后将观察结果（Observation）反馈至上下文，模型据此进行下一轮推理并请求后续工具。这种线性交互模式在受控演示中表现优异，却在生产环境中暴露出结构性脆弱：当工具返回万行级数据库记录，当候选工具规模扩展至数百个，当中间结果持续膨胀上下文窗口，Token 成本、响应延迟与幻觉风险将呈指数级上升。

为应对这些单任务执行层面的工程痛点，现代 Agent 架构完成了第一次关键进化。 不再让模型在对话回合中反复发起工具调用，而是赋予其编写代码以编排工具的能力。通过程序化工具调用（Programmatic Tool Calling），模型在隔离沙箱中生成 Python 代码：并行调用多工具、过滤原始结果、聚合结构化数据、执行确定性计算，仅将精炼后的结论（如"符合条件的订单共 42 个"）返回至模型上下文。原始数据从未直接进入语言模型的推理视野。

与此同时，可重复的工作流正在被固化为 Skills（技能）。一个 Skill 不再是一段脆弱的提示词，而是一个结构化的、版本化的工作流包，包含 README 描述、SQL 模板、邮件模板、示例输出与元数据。Agent 在运行时动态检索并加载这些技能，确保行为的一致性与跨会话的可复现性。

调用、编排工具的能力是 Agent 第一次进化的核心，并基于此演化出 Skill 工程，但仍面临“单任务执行正确，但任务组合起来的全局执行效果无法验证”的困局

这次进化使 Agent 成为了真正可靠的"任务执行者"：

· 上下文工程（Context Engineering）： 将上下文窗口视为受管理的计算预算，而非无限内存。通过代码执行层进行数据过滤，确保原始记录（如万行级数据库输出）永不直接污染模型上下文。

· 技能化（Skills）： 将专家知识封装为可版本控制的模块，支持工具搜索与渐进式加载（Progressive Disclosure），使 Agent 能在数百个候选工具中精准定位所需能力，避免"工具泛滥"导致的决策混乱。

· 确定性计算： 将数学运算、逻辑判断与数据聚合等操作保留在代码执行层，利用 Python 的确定性执行替代 LLM 的概率性"猜测"，从根本上消除计算类幻觉。

然而，Skills 与上下文工程解决了"如何正确执行单个动作"的问题，却并未解决"如何确保多动作组合后全局正确"的问题。当单任务执行变得如此稳定可靠时，极易误以为 Agent 已具备交付复杂项目的能力。事实恰恰相反——这仅仅是"任务执行者"与"项目交付者"之间分水岭的起点。

尽管 Skills 和程序化调用已经大幅提升了 Agent 的单任务表现，但依然面临一个更深层的能力断层。当前的 Agent 可以出色地完成单一任务（Task），却无法交付复杂项目（Project）。

想象一个"个人旅行助手" Agent。配备了相应的 Skills，它可以：

· 调用搜索工具，返回详尽的东京旅行攻略

· 调用预订 API，成功锁定一家高评分酒店

· 调用航班接口，为你购得往返机票

然而，你无法信任它为你制定一份"确保不出错的完整旅行计划"。 它无法保证酒店退房日期与航班起飞时间的时间逻辑合理性；无法在预算超支时自动降级酒店并重新匹配航班；不能在台风导致航班取消时，自动重构整个行程链并重新预订可退款的替代方案。换句话说，它能执行动作，但不能规划系统；能遵守指令，但不能维护全局约束条件。

这种局限性的根源在于：

· 缺乏全局规划层： Skills 是孤立的，Agent 没有一种通用方法来描述"酒店日期必须早于航班日期"这类跨领域约束。

· 无法验证正确性： Agent 只能"希望"各个步骤的结果组合起来是正确的，而无法在执行前或执行中证明其正确性。

· 无自动重构能力： 当约束条件变更（如预算削减、时间调整），Agent 无法像软件工程师那样自动重构代码逻辑以适应新约束，只能重新尝试，甚至陷入循环。

基于 Skill 工程的 Agent 实质上缺乏对任务全局的足够认识。在编程领域，业界已经敏锐地意识到了这一断层，形成了Spec 驱动开发+harness概念的实践。

业界已经敏锐地意识到了这一断层。Spec 驱动开发（Spec-Driven Development, SDD）正成为 Agent 编程领域的关键趋势，代表性项目如 Spec Kit 和 Agent Spec [2] 试图通过引入"规范层"来弥补 Skills 缺乏全局认识的缺陷。

· Spec 显式定义契约：通过结构化规范将需求转化为可版本控制的"活文档"，明确任务目标与验收标准，解决"做什么"的问题；

· Harness 构建执行闭环：作为"模型之外的一切"，它集成代码沙箱、文件系统持久化、Ralph 循环续写与自我验证机制，让 Agent 能在受控环境中维持状态、执行代码并自我纠错，解决"怎么做并确保做对"的问题。

然而，这一范式本质上仍局限于相对聚焦的编程沙箱：它假设问题可拆解为代码文件、可通过测试用例验证、可在确定性环境中执行。当面对真实世界的通用问题——如跨系统资源编排、动态供应链调整或开放域旅行规划——Harness 的"写代码-运行-观察"闭环便显得力不从心：它缺乏对非代码实体（如时间、预算、物理资源）的形式化描述能力，无法验证跨域约束（如"酒店日期早于航班"这类时序逻辑），更难以在约束突变时自动重构全局方案。要突破这一边界，需要一个能够描述通用问题的计算模型——它必须具备对象化建模、关系表达、形式化验证与动态重构的能力。

要跨越从任务到项目的鸿沟，Agent 必须获得一项元能力：对复杂问题进行形式化建模与自动化求解。这不仅是从"工具调用"到"编写代码"的升级，更是从"执行指令"到"构建问题本体"的范式跃迁——Agent 需要成为"模型驱动的问题解决者"。

前面章节所述的"程序化工具调用"只是第一步。更深层的模式是：当面对一个复杂项目时，Agent 不再直接编写执行代码，而是首先基于 CBE 范式对问题进行 Component-Based 建模——以东京之行为例，将行程拆解为 HotelStay（酒店住宿）、AttractionVisit（景点参观）、Dining（餐饮）等形式化的 Activity 组件，以及连接它们的 Transportation（交通接驳）。每个组件显式定义其属性（入住/退房时间、景点开放时段、交通班次与耗时）、接口（输入：旅客人数与偏好；输出：预订状态与预计到达时间）与约束条件（如"退房时间必须早于下一程交通出发时间"）。跨组件的约束则体现为交通可及性（酒店与机场间的通勤逻辑）、预算池总量与每日时间窗口（同一日内的活动序列总时长不得超过可用时间）等形式化规则。这个模型本身就是对旅行问题域的本体化描述（Ontology），它将模糊的"规划行程"转化为可计算的、由 Activity 节点与 Transportation 边构成的时序依赖网络。

问题描述+数据 -- 自动化构建器 --> 问题本体（包含形式化约束） -- CBE编程器 --> 可验证求解的程序

基于这一模型，Agent 自动生成仿真程序来模拟问题环境，并运用通用算法（约束满足、优化求解、状态空间搜索等）在模型空间中推演可行解。生成的程序不再是即兴的脚本，而是模型驱动的、可验证的执行计划：它定义了如何调用工具、如何控制数据流、如何在约束冲突时进行回溯与重构。当求解成功，该问题模型及其求解策略被封存为一个可复用的 Skill。

这种"问题建模 → 自动求解 → 固化模型"的闭环带来了根本性的优势：

· 上下文预算的绝对控制：在建模层，Agent 通过模型显式定义 filter()、aggregate() 逻辑，确保只有经过结构化计算的模型状态（如"当前预算池：$500，可用时间窗口：[T1, T2]"）进入 LLM 上下文，而非原始的、未过滤的票据列表或环境噪音。

· 确定性的计算结果：所有数值计算、逻辑判断、约束验证都在基于模型生成的代码执行层完成，利用 Python 的确定性执行替代 LLM 的概率性"猜测"，从根本上消除计算类幻觉。模型即契约，执行即验证。

· 技能的自动演化：Agent 解决复杂项目的过程，本质上是积累问题模型库的过程。成功的项目模型经过抽象后，自动进入 Skills 库，成为解决未来同类问题的构建块——不再是孤立的代码片段，而是带有形式化语义的可复用组件。

一个值得思考的问题是：应该用什么样的"语言"来让 Agent 理解和建模问题？太具体的语言（如特定领域的 DSL）会导致每个新问题都需要重新设计语法；太泛泛的语言（如自然语言或纯代码）则缺乏结构，无法支撑自动化的验证与求解。需要的是一种既足够固定（以支持通用算法），又足够灵活（以覆盖广泛问题域）的中间层设计模式。

CBE（Component-Based Engineering，基于组件的工程）正是这一中间层的答案。

（一）固定性的价值：通用求解算法的基石

首先承认一个反直觉的事实：要让 Agent 聪明地处理复杂问题，必须先限制它表达问题的方式。

Skill 工程的局限性在于其"开放性"——每个 Skill 都是孤立的代码单元，内部逻辑可以任意编写。这种任意性导致了两个致命后果：第一，Agent 无法在 Skill 之间建立形式化的关联（如"酒店退房时间必须早于航班起飞时间"）；第二，系统无法对 Skill 的组合进行全局分析，只能盲目执行。

CBE 通过引入固定的元模型（Meta-Model）解决了这一问题。在 CBE 中，任何问题都必须被分解为三类严格定义的元素：

· Component（组件）：具有状态、接口和生命周期的对象化实体

· Connection（连接）：组件间的拓扑关系与数据流

· Constraint（约束）：跨组件的谓词逻辑，定义合法状态空间

这种固定的结构不是束缚，而是为通用求解算法铺设的轨道。一旦问题被形式化为 Component-Connection-Constraint 的三元组，就能够：

· 应用约束满足（CSP）算法验证方案可行性

· 运用优化理论在多重约束下寻找帕累托最优

· 基于状态空间搜索进行自动化的回溯与重构

固定性带来了可计算性。 正如关系型数据库凭借固定的表结构成就了 SQL 这一通用查询语言，CBE 凭借固定的组件元模型成就了"通用问题求解语言"。没有这种固定性，每个项目都将是特设的（Ad-hoc），Agent 永远停留在"试错"而非"求解"的层面。

（二）灵活性的必要性：问题域的无限多样性

然而，仅有固定性是不够的。如果 CBE 只能建模软件系统或特定的工程问题，它就无法支撑 Agent 向"通用项目交付者"演进。需要的固定是元层面的固定，而在实例层面必须保持极端的灵活性。

CBE 的灵活性体现在三个维度：

第一，组件语义的完全开放性。 CBE 并不规定组件必须是"微服务"、"类"或"模块"。一个 Component 可以是：

· 旅行规划中的 HotelStay（具有入住/退房时间属性）

· 供应链中的 InventoryBatch（具有保质期、位置、批次号）

· 研发流程中的 CodeReview（具有审查者、状态、阻塞Issues）

· 金融模型中的 SwapContract（具有浮动利率、到期日、对手方风险）

只要实体可以被对象化（具有状态和行为），它就可以成为 CBE 中的 Component。这种开放性使 CBE 能够无缝适配任何可以被面向对象方式理解的领域。

第二，约束表达的组合性。 CBE 不限制约束的复杂度。从简单的算术不等式（budget.spent

第三，组合拓扑的动态性。 组件间的连接不是静态的架构图，而是在求解过程中动态生成的依赖网络。在旅行规划中，Agent 可能在求解阶段发现"酒店-机场"的组合需要插入额外的GroundTransportation组件；在供应链场景中，可能需要动态插入AlternativeSupplier来满足突发约束。CBE 的 Composition 层允许这种"求解时架构"（Architecture at Solve-time），这是静态设计模式无法企及的灵活性。

（三）CBE 适用性边界

CBE 范式适用于结构清晰、约束可形式化的问题域（如资源调度、行程安排、供应链优化、软件系统架构）。其优势在于处理具有明确对象、可量化属性、显式拓扑关系的系统。对于边界模糊、目标函数难以形式化、强依赖主观解释的领域（如品牌策略制定、人际关系协调、开放式创意设计），CBE 的刚性结构反而可能成为约束，此类场景下传统对话式 Agent 或人机协同模式更为适宜。

CBE Agent 要成功运行，必须先回答一个前置问题：它如何知道一个旅行项目涉及哪些对象、属性、关系和约束？ 换句话说，Agent 需要获取问题的本体（Ontology）。

本体是 CBE 的基石。没有形式化的领域本体，Agent 就无法生成符合 CBE 规范的组件。本体的构建不是一个单纯的 AI 问题，而是一个知识工程（Knowledge Engineering）**问题。它描述了一个特定问题域的元结构：

· 涉及哪些对象： 航班、酒店、预算、时间窗口、用户偏好；

· 对象有哪些属性： 航班的起飞时间、酒店的取消政策、预算的币种；

· 对象之间有什么连接关系： 航班的到达城市与酒店的所在城市必须一致；

· 约束条件（全局/局部）： 全局预算上限是硬性约束，酒店星级偏好是软性约束。

本体的构建流程是连接人类专家与自主 Agent 的关键桥梁：

· 专家输入： 领域专家（如资深旅行规划师）首先用自然语言描述问题场景，定义业务规则与边缘案例。这是不可自动化的部分，捕捉的是人类默会知识。

· 自动化抽取： 利用本体自动抽取技术（参考实验室的自动化本体构建方法V3.0），将场景描述转化为形式化的本体表示。需特别说明的是，当前自动化抽取技术主要适用于结构化程度较高、领域知识已有标准化表述的问题域（如金融合约、供应链节点、IT系统架构）。

· CBE 程序生成： 配备本体的 Agent（可称为 Agentic Coder）基于 CBE 范式，生成本体中定义的组件并自动注入本体中声明的约束作为组件契约。

· 问题解决： 生成的 CBE 程序被调用执行，解决具体问题。成功的程序经抽象后反哺 Skills 库。

这是一个从"人类知识"到"机器可执行的形式化系统"的完整 pipeline。 专家不再直接编写代码，而是定义本体；Agent 不再盲目尝试，而是基于本体进行可验证的构建。

 Agent 架构的代际正在更替。上一代 Agent 追求"能说话、能调用工具"，下一代 Agent 必须追求"可验证、可维护、可交付"。CBE Agent 代表了这一进化的工程化目标：它融合了程序化工具调用的效率、CBE 的工程严谨性、以及知识工程对领域本质的捕捉。

更具深远意义的是，这种工程化成熟度将重构Agent的商业价值基础。当前Token计费模式的本质是为'计算过程'付费，导致生成错误答案与正确答案消耗同等算力。CBE带来的确定性使'结果导向计费'（Outcome-based Pricing）成为可能：用户不再为中间推理Token付费，而是为'成功交付的东京旅行规划''零冲突的供应链排期'等可验证结果付费。从'为努力付费'到'为价值付费'的跃迁，标志着Agent从实验性工具转变为可签约的商业服务。