🧭 Agent 工程化五维度框架

Agent 工程化不是零散技巧的堆积——它需要一个系统性的分析框架。五维度框架（架构/数据/测试/稳定性/产品）提供共享语言。

🔍 为什么 Agent 工程化需要一个框架

2025-2026 年，Agent 从「写一个 Prompt 让 AI 回答」进化到「让 AI 自主规划、调用工具、多步执行」。这个跃迁带来了工程化的真问题：

• 单 Agent 的 Prompt 可以用经验调试，但多 Agent 编排需要系统性的设计语言——你不能对 3 个互相调用的 Agent 分别「调 Prompt」，它们会在交互中涌现出个体调试无法预测的行为。
• Agent 的行为不是 Prompt 的线性函数。同一份 Prompt，在不同上下文、不同工具返回、不同模型版本下，产出可以天差地别。这需要一种超越 Prompt 层面的抽象来管理。
• 88% 的 AI Agent 从未进入生产（Digital Applied 2026）。失败不是模型不够好——是工程化基础设施的缺失。需要一个框架来定位差距。

五维度框架的定位：不是「怎么做 Agent」的操作手册——是「从哪些维度审视 Agent 工程化质量」的分析矩阵。

🧩 维度一：架构设计

核心命题：Agent 的能力如何被组织？

• SKILL-as-Function/Service 模式：每个 SKILL 是一个独立的函数单元，有明确的输入/输出契约。这是 Agent 工程化的最小可组合单元——对应软件工程中的「单一职责原则」。
• MCP（Model Context Protocol）2026：10,000+ 活跃服务端、97M+ 月 SDK 下载。MCP 标准化了 Agent 与外部工具/数据的交互方式，使 SKILL 的「调用外部能力」部分不再依赖临时实现。
• 编排层：任务分解→Agent 路由→结果合成。Deloitte 2026 将编排层称为「conductor of the AI orchestra」——它不执行具体任务，但负责判断「这个任务该由哪个 Agent 做、以什么顺序做、中间结果如何传递」。

架构设计的核心原则：Agent 之间的边界必须比 Agent 内部逻辑更清晰。

🧩 维度二：数据分层

核心命题：Agent 需要什么信息才能正确决策？这些信息按什么层级组织？

• 事实层（Fact Layer）：不可变的客观数据——API 文档、数据库 Schema、代码仓库结构。更新频率低，错误容忍度为零。
• 规则层（Rule Layer）：项目/团队的编码规范、架构约束、禁止项清单。半稳定——随项目演进更新，但频率可控。
• 经验层（Experience Layer）：过往的调试记录、最佳实践、失败案例。高频更新，随每次交互累积。
• 元认知层（Meta Layer）：Agent 对自身能力的认知——「我能做什么、不能做什么、什么时候该请求人类介入」。这是最不稳定但最关键的一层。

四层数据不是平行的——它们是递进的。事实层是地基，规则层加载约束，经验层提供上下文，元认知层决定边界。任何一层断裂，上层全部失效。

🧩 维度三：测试体系

核心命题：你怎么知道 Agent 做对了？

• L1 单元测试：单个 SKILL 的功能正确性——「给定这个输入，产出是否匹配预期？」。
• L2 编排测试：多 SKILL 协作的流程正确性——「A 的输出→B 的输入→C 的决策，中间状态是否正确传递？」。
• L3 系统测试：端到端场景——「真实用户请求→Agent 完整处理→最终产出是否符合业务预期？」。
• Golden Dataset：精选的「正确答案已确认」的用例集。每次 Agent 迭代后用 Golden Dataset 回归——这不是可选，是 L2/L3 测试的基准。

测试体系的核心理念：Agent 的不可预测性不是测试面临的特殊困难——它恰恰是测试体系必须存在的原因。

🧩 维度四：稳定性

核心命题：Agent 如何在不确定性中保持输出质量？

• Reflection 模式：Agent 产出→自我审查→修正。这是最基础的稳定性机制——先做，再看，再改。
• Plan-Solve 模式：先规划再执行。规划阶段冻结决策路径，执行阶段不可偏离——这和 SDD 的 Spec-Anchored 概念是同构的。
• Tool-Use 确定性：让 Agent 调用确定性的外部工具（计算器、数据库查询、API 调用）而非依赖模型内部的推理。模型的推理不可靠，工具的返回可靠。
• Multi-Agent 校验：两个 Agent 独立处理同一任务，结果不一致时报警。交叉验证的成本是双倍 token，但收益是故障检测覆盖了模型内部的未知偏差。
• HITL（Human-in-the-Loop）：在关键决策点设置人工审批。不是所有步骤都需要——只在「错误成本 > 审批成本」的节点。

🧩 维度五：产品

核心命题：Agent 如何被用户/团队接受和信任？

• 混合交互模式：Agent 不是「替代人」——是「在执行层替代重复劳动，在决策层提供信息让人做判断」。不要追求全自动。
• 渐进式信任：从「Agent 建议→人确认」到「Agent 执行→人抽查」到「Agent 自主→异常报警」。信任不是开关，是梯度。
• 成本分离：Token 成本、人工审核成本、错误修复成本要分开计量。把三者混在一个「总成本」里会掩盖真实瓶颈——往往是修复成本远高于 Token 成本，但修复成本的来源是前三层（架构/数据/测试）的缺陷。

❓ 伏笔：框架是分析工具 —— 分析工具能保证交付吗？

五维度框架让你知道「Agent 的质量从哪些维度衡量」。但它不回答一个更紧迫的问题：知道这些维度之后，为什么 88% 的 Agent 还是上不了线？ 如果框架是正确的——如果这五个维度确实覆盖了 Agent 工程化的完整空间——那么 88% 的失败率意味着什么？是框架被忽视了，还是框架本身缺少了什么？

_{方法层 · 第一篇 | dialectical position: Thesis | next: Antithesis — 88% 的裂缝}