30篇论文总结Harness Engineering：AI 智能体的系统化架构方法论

摘要

支架工程（Harness Engineering）是一门新兴的架构学科，其核心目标是围绕 AI 智能体（Agent）构建一套结构化的运行环境——“支架”——通过精确设计的上下文交付系统、工具接口、规划工件、验证循环、记忆管理和沙箱执行环境，使智能体能够在真实任务中高效、安全和可靠地执行。与传统 AI 开发范式侧重提升模型能力不同，支架工程认为智能体能力的瓶颈往往不在于模型本身，而在于其所在环境提供的上下文质量、约束机制和反馈回路。支架（Harness）一词本身即是高度结构化的隐喻，以骑马类比：模型是马，上下文是视野，支架才是缰绳、马鞍与路。本文系统梳理了支架工程的理论框架与技术实现，围绕分层上下文系统、计划优先工作流、安全反射与行动闸门、评估支架、沙箱隔离与工具接口五大核心支柱展开论述，分析各组件的设计原则、关键技术细节与理论基础，并结合当前学术前沿与产业实践讨论其发展前景。

关键词： 支架工程；脚手架工程；AI 智能体；分层上下文系统；计划优先工作流；安全反射；执行轨迹评估；沙箱隔离；模型上下文协议

1 引言

AI 智能体（AI Agent）被定义为“由语言模型驱动的、能够在多次迭代中规划并执行动作以实现复杂目标的实体”。近年来，智能体的能力边界不断拓展，已能够在真实世界中自主完成编码、调试、部署、数据分析等多步骤任务。然而，能力的提升也伴随着新的挑战：智能体在多步执行中容易发生错误累积、上下文衰减、安全越界等问题，这些问题的根源往往不在模型能力本身，而在其运行环境的设计缺陷。

在此背景下，AI 辅助编程的范式经历了从“提示词工程”（Prompt Engineering）到“上下文工程”（Context Engineering）再到“支架工程”（Harness Engineering）的三级跃迁。研究表明，从2022到2026年，研究重心正从 Weights（预训练、Scaling Law）转向 Context（RAG、长上下文），再转向 Harness（MCP工具生态、安全、多Agent协作）。三者的关系可理解为包含而非替代：Prompt ⊂ Context ⊂ Harness——提示词关注如何表达任务，上下文关注模型在执行任务时看到什么，支架关注模型运行其中的系统级约束与验证架构。

表1: Prompt、Context 与 Harness 的三层范式对比

支架工程正是在这一范式演进中作为系统性方法论被提出。其核心洞察在于：模型能力正在趋同，支架是 Agent 时代的真正护城河。 正如 Anthropic 在实践中积累的经验所示，CLAUDE.md 常被视作项目上下文的“最主要的事实来源”，通过编码项目约定、测试命令和架构说明，确保 Agent 收敛于共享标准。本文旨在对支架工程的理论框架与技术实现进行系统综述。后续章节分别讨论分层上下文系统（第2章）、计划优先工作流（第3章）、安全反射与行动闸门（第4章）、评估支架（第5章）、环境隔离与工具接口（第6章），最后给出总结与展望（第7章）。

2 分层上下文系统

2.1 上下文衰减问题与分层缓存的提出

支架工程的分层上下文系统根植于对“上下文衰减”（Context Decay）问题的深刻认识。LLM 在处理长上下文任务时面临持续的挑战，最为突出的是 “迷失在中间”（lost in the middle） 问题——长输入中位于中间位置的信息往往被模型低效利用。这一问题可进一步分解为两种机制：注意力分散（attention dispersion），即随着输入长度的增加，模型对关键指令的注意力权重被稀释；以及位置偏置（position bias），即模型天然地对序列首尾位置的 Token 给予更高权重。

为应对这一问题，学术界提出了多种策略。Global Context Manager 是一类架构组件，通过聚合、压缩和注入系统级上下文，使用层级Transformer、注意力池化和 RL 驱动的策略平衡局部与全局信号，在多样化应用中改善了任务性能和记忆效率。Context-Focus Window Mechanism 通过指针式外部记忆例程，将超出上下文限制的工具输出存储到键值运行时库，Agent 仅接收轻量指针，在多步化学工作流中实现了约7倍的 Token 缩减。Tree of Agents（TOA）则采用多智能体推理框架，将输入分割为块并由独立 Agent 处理，通过动态信息交换沿树结构路径进行多视角协同推理，由紧凑型 LLaMA3.1-8B 驱动时，在多种长上下文任务上展现了与更大型商业模型相当的性能。

支架工程的分层上下文系统从一个不同的角度切入：与其扩展上下文窗口或压缩信息，不如将上下文视为一种分级缓存机制——精确控制在不同任务阶段喂给模型的信息量。这一设计的灵感直接来自计算机体系结构中的缓存层级设计（L1/L2/L3 Cache），在工程实践中形成了从全局宪法到按需加载的模块文档的完整层次。

2.2 分层架构的具体设计

分层上下文系统从顶层到底层依次为：

第一层：根规则文件（代码库“宪法”）。 通常命名为 AGENTS.md 或 CLAUDE.md 文件。CLAUDE.md 是唯一默认进入每一次与 Agent 对话的文件，这意味着其中的每条指令都会消耗 Token 预算，同时也享有最高的注意力权重。因此，宪法层仅应包含智能体“无法通过阅读代码推导出的部落知识”——如非直观的架构规则、多租户隔离准则、版本隔离策略和项目独有的编码禁令——而非通用的编码建议或已经内化于模型训练数据的知识。

OpenAI 联合 Amp、Google Jules、Cursor 等厂商于2025年初推出的 AGENTS.md 标准，进一步将这一实践规范化。该标准采用 Apache 2.0 许可证，作为供应商中立的编程 Agent 指导文件协议，允许多种 AI 工具读取共享项目上下文。其与 README.md 的功能边界明确：README 面向人类开发者，AGENTS.md 面向 AI Agent。为保持注意力集中，宪法层应控制在约55行以内。

第二层：安全反射（Safety Reflexes）。 由3-5行组成的微型规则文件（详见第4章），针对高成本错误构建类似“肌肉记忆”的防御性推理模式。这些规则在每一个会话中都被加载，利用条件式逻辑（“如果你正在做 X，就必须做 Y”）在关键推理环节进行瞬时干预。

第三层：特性百科全书（Feature Encyclopedias）。 为每个核心功能模块创建约60行的独立文档，包含实体 Schema、关键文件路径、副作用注册表、版本可用性（社区版 vs. 企业版）和规范化领域术语。当 Agent 探索具体功能时按需加载，避免了传统模式下 Agent 通过 read_file 工具调取数十个源文件猜测逻辑关系所带来的信息过载和 Token 浪费。

第四层：技能与编码流程（Codified Workflows）。 将复杂的多步操作（如添加 API 端点、执行数据库迁移）固化为斜杠命令（例如 /add-endpoint），为 Agent 提供不可轻易偏离的固定执行路径。Knowledge Activation 框架（2026）进一步将此概念形式化——将 AI 技能定义为“可组合的知识图谱”，使 Agent 能够在运行时遍历知识节点，有效压缩入职成本并消除纠错级联效应。

第五层：专项子智能体（Scoped Subagents）。 通过建立“上下文防火墙”将任务分派给职责明确的子智能体（如分别负责前端、后端、更新日志），每个子智能体拥有独立且受限的工具权限和代码路径访问权限，在物理层面切断了跨领域的信息噪音。

2.3 分层上下文的运行时调度

分层上下文系统的运行时行为遵循“渐进式披露”（Progressive Disclosure）原则。Agent 初始化时仅加载宪法层和安全反射层（约150行指令），当且仅当 Agent 进入特定功能模块的探索阶段时，支架才动态加载对应的特性百科全书。当 Agent 调用特定技能命令时，支架进一步注入该技能的结构化工作流。这种按需加载机制确保了活跃上下文始终处于模型注意力质量最高的“甜点区”。

研究表明，分层上下文的运行时机制可对应三个关键环节：上下文凝聚（context condensation），将大量源文件的信息压缩到简洁的功能摘要中；相关性驱动选择（relevance-driven selection），仅在当前子任务相关时才触发文档注入；以及 RL 驱动策略，学习最优的信息注入时机与粒度。

2.4 配套机制：计划优先工作流与 .agents/ 目录架构

分层上下文系统必须配合计划优先工作流才能实现最大效能（详见第3章）。在执行代码前，Agent 必须根据当前层级的上下文产出一份结构化计划；人类开发者在计划阶段审查 Agent 的意图而非代码。这种分离确保了上下文信息在推理阶段的充分消费，而非在盲目编码中被浪费。

在物理组织层面，为了在多个 AI 工具（Claude Code、Cursor、Aider、Windsurf 等）间维护一致的上下文配置，现代支架工程通常将所有核心逻辑存储在独立的 .agents/ 目录中，并通过符号链接映射至特定工具的配置文件夹（例如 ln -s .agents/rules .claude/rules）。.agents/features/ 存放模块百科全书（通常包含40多个独立的 Markdown 文件，每个约60行），.agents/skills/ 存放编码化工作流，.agents/rules/ 存放安全反射规则。这种“工具中立”的设计确保了支架的内容可以比任何一个特定 AI 平台更长久地存在。

3 计划优先工作流

3.1 理论基础：推理与执行的分离

计划优先工作流（Plan-First Workflow）的核心思想是将智能体的“推理/规划”与“执行”进行架构级分离。在传统的 ReAct（Reason + Act）模式下，Agent 在每一个动作步骤中进行局部推理，逐步推进任务。这种交错执行的模式虽然在简单任务中表现良好，但在涉及多个文件和长期依赖的复杂任务中，容易因早期步骤的微小错误产生累积效应——错误在后续步骤中被放大，最终导致输出完全偏离用户需求。

Plan-then-Execute（P-t-E）模式对此提出了根本性的改进。Krawiecka 与 Del Rosario 等将 P-t-E 定义为一种智能体设计模式，将战略规划（strategic planning）从战术执行（tactical execution）中分离，其核心组件包括 Planner（规划器）和 Executor（执行器）。与 ReAct 等响应型架构相比，P-t-E 在可预测性、成本效率、推理质量和安全韧性方面均展现出架构性优势。Source Code Agent 框架将这一思想进一步推向极致，提出“Blueprint First, Model Second”哲学，将工作流逻辑从生成模型中彻底解耦——由领域专家定义的操作程序被编码为基于源代码的执行蓝图（Execution Blueprint），再交由确定性引擎执行，从而消除 LLM 非确定性带来的变异风险。

3.2 核心流程：四阶段分离

计划优先工作流包含四个关键阶段：

在计划模式（Plan Mode）下，Agent 被强制约束为只读模式——不得修改任何代码。它利用支架中的语义搜索工具探索代码库，阅读相关的特性百科全书文档，并提出澄清性问题。最终产出的结构化计划必须明确说明：需要创建/修改的具体文件路径、API 的数据形状（Schema）、测试方案以及预期的影响范围。

3.3 计划工件与跨会话持续性

支持计划优先工作流的支架工程引入了专用的计划工件（Planning Artifact）。PLAN.md 或 Implement.md 文件持久化存储 Agent 的推理路径、里程碑和中间决策，实现了跨会话的任务恢复。当长任务因会话超时或上下文溢出而中断时，新会话中的 Agent 可以直接读取计划工件，从上次中断点继续执行，而无需重新探索代码库或重新推理整个任务。

3.4 安全架构与防御纵深

从安全角度，P-t-E 模式的架构优势不仅体现在推理质量上。Del Rosario 等的深入分析表明，P-t-E 通过建立控制流完整性（control-flow integrity），天然具备对间接提示注入攻击的韧性——Executor 仅执行 Planner 已审定的操作序列，外部注入的恶意指令无法绕过 Planner 改变执行路径。当然，作者同时强调 P-t-E 是防御纵深的基础层而非完整解决方案，必须辅以最小权限原则（PoLP）、任务范围工具访问限制和沙箱化代码执行等补充控制。

3.5 评估关联：计划质量与计划依从性

在评估层面，计划优先工作流催生了两个关键的推理层评估指标：

• • 计划质量（Plan Quality）： 评估计划本身的逻辑性（步骤序列是否符合因果和技术逻辑）、完整性（是否覆盖用户简报中的所有关键需求）和效率性（是否为达成目标的最优路径）。
• • 计划依从性（Plan Adherence）： 衡量 Agent 在实际执行中是否忠实于其预设计划，识别跳步、乱序调用工具或中途产生幻觉偏离路线的情况。

4 安全反射与行动闸门

4.1 双重防御体系的理论基础

安全是支架工程从设计之初就嵌入的核心关切。在支架工程的体系中，安全防护依托于一种双重防御架构：

• • 安全反射（Safety Reflexes）： 工作在模型的思考阶段，通过极其精简的上下文工程影响推理过程，形成推理层面的“自律准则”。
• • 行动闸门（Action Gates）： 工作在模型的行动前夕，在 Agent 已决定调用工具后、代码或命令真正运行前进行确定性拦截，形成执行层面的“强制约束”。

这两道防线的设计哲学可追溯至认知神经科学中“系统1/系统2”的双过程理论——安全反射模仿了快速、自动化的习惯性防御（系统1），行动闸门则类似审慎、确定性的规则检查（系统2）。

4.2 安全反射的设计原理与实现

安全反射被定义为分层上下文系统的第二层级。其设计遵循严格的极简原则：每个规则文件仅包含3-5行指令，参数化为“如果你正在做 X，就必须做 Y”的条件逻辑。

从信息论角度看，安全反射的有效性根植于 LLM 对规则的编码与遵循机制。系统性研究表明，系统提示词中规则的编码方式（位置、密度、语义明确性）显著影响模型的注意力分配和遵循行为。安全反射通过在上下文的最顶层位置（享有最高注意力权重）注入高频代价指令，利用模型的指令遵循能力在关键推理环节进行瞬时干预。

在实践中，安全反射通常存放在 .agents/rules/（或 .claude/rules/）目录下，包含以下类型的规则：

安全反射的理论渊源可进一步追溯到 Meta-Policy Reflexion（MPR）框架。MPR 将谓词式记忆与硬性准入检查结合，通过在提示词中注入相关规则来偏置解码过程朝向安全有效的行动路径。其关键见解在于：Agent 的记忆不仅是“学到了什么”，更应该是“什么规则必须被遵守”。

4.3 行动闸门的实现原理与技术栈

行动闸门采用确定性策略拦截机制，与安全反射的“提示词影响推理”形成互补。其核心技术组件包括：

符号规则验证门控（Symbolic Rule Verification Gating）。 一种混合编排层，在 Agent 的计划动作执行前，将其与硬编码的符号逻辑规则集进行比对评估。该系统集成 Open Policy Agent（OPA）和 Rego 策略语言，对每一次工具调用和 API 请求进行执行前审计。

Policy-as-Code。 将安全、合规和访问规则转化为可执行代码，取代脆弱的手动流程。通过 OPA/Rego 等工具嵌入 AI Agent 基础设施，每次决策在真正执行前都会经过“允许/拒绝”的二元判定，决策的输入、输出和判定结果被全量记录为审计追踪。

运行时控制。 Unified Plan Verification 框架在 LLM Agent 的计划前后插入显式校验。静态验证（SVR）在执行前将通用分类法（完整性、正确性、可执行性）实例化为特定任务的双元检查表；动态验证策略（DVP）在执行中消费步骤上下文和工具输出，发出符号动作（接受/下一步/切换/跳过/回溯）。

ShieldAgent。 作为首个专门设计的 Agent 安全护卫系统，ShieldAgent 通过构建安全策略模型——从策略文档中提取可验证规则，构建为基于动作的概率规则电路——在被保护 Agent 的动作轨迹上执行逻辑推理与形式验证。在包含3K安全相关测试对的 ShieldAgent-Bench 上，ShieldAgent 实现了90.1%的高召回率和平均11.3%的性能提升。

Agent 安全治理框架。 AGENTSAFE 框架将 AI 风险仓库（AI Risk Repository）操作化为覆盖设计、运行时和审计三类控制的完整治理流水线。它剖析智能体循环（规划→行动→观察→反思）和工具链，将风险映射到扩展了 Agent 特定漏洞的结构化分类法上，通过语义遥测、动态授权、异常检测和可中断性机制实现持续治理。

4.4 双重防线的协同机制

安全反射与行动闸门在以下维度上形成互补：

两者的协同产生了“纵深防御”效果：安全反射通过使 Agent 在推理阶段“更聪明”来预防错误想法的产生，行动闸门则作为最后的防线，在错误想法试图转化为行动时进行强制拦截。

5 评估支架

5.1 从单轮评估到全轨迹评估

支架工程的评估体系代表了一次根本性的评估哲学转型：从关注“是否达成目标”转向关注“如何达成目标”。传统 LLM 评估范式聚焦于单一的“输入-输出”对——给定一组测试用例，比对模型输出与预期答案的匹配程度。然而，Agent 的评估需要拓展为对行动轨迹的多步骤分析。

这一转型的关键原因在于 Agent 特有的不确定性本质：相同的任务请求在多次执行中可能产生完全不同的工具调用序列。两个 Agent 可能都成功完成了任务，但其中一个的效率可能是另一个的两倍；一个 Agent 的最终输出虽然正确，但其执行路径可能留下了难以察觉的安全隐患。因此，完整的 Agent 评估必须包含轨迹分析。

TRAJECT-Bench 作为轨迹感知的评估基准，通过细粒度评估指标揭示了工具混淆和参数盲选等失败模式。TRACE 框架则更进一步，通过引入证据库（Evidence Bank），在没有真实标注的情况下对工具增强的 LLM Agent 进行多维度轨迹评估。

表6: 代表性 Agent 评估基准对比

5.2 多层级评估指标

完整的执行轨迹评估在以下层级进行：

推理层指标：

• • 计划质量（Plan Quality）： 评估 Agent 在执行前制定的初始计划的合理性。高质量计划需满足三个维度——逻辑性（步骤序列是否符合因果和技术逻辑）、完整性（是否覆盖了用户简报中的所有关键需求）和效率性（是否为达成目标的最优路径）。
• • 计划依从性（Plan Adherence）： 衡量 Agent 的实际执行是否忠于其预设计划。通过比对计划中的步骤序列与实际执行中的工具调用序列，计算跳步率和乱序率。高依从性意味着 Agent 的推理输出是“言行一致”的。

行动层指标：

• • 工具选择准确性： 比对 Agent 实际选择的工具与预设正确答案的匹配度。
• • 参数正确性： 验证工具调用中的参数值是否源自现有上下文而非凭空捏造。
• • 路径有效性： 通过分析追踪记录识别无限循环、冗余调用或不必要的回溯。

端到端指标：

• • 步骤效率（Step Efficiency）： 实际执行步数与理论最短路径的对比。
• • 任务成功率（Task Completion Rate）： 任务是否最终达成。
• • Token 效率： 完成任务消耗的总 Token 数（反映经济成本）。

5.3 评估方法论：从 LLM-as-Judge 到 Agent-as-Judge

评估方法分为两类：

确定性检查。 适用于可预期输出的验证，通过精确比对工具名称、参数格式和 API 状态码实现零误差评估。这种方法速度快、成本低，但仅适用于封闭式指标。

LLM-as-Judge。 对于开放式的响应质量或逻辑对齐，使用能力更强的模型（如 GPT-4 或 Claude Opus）根据预设量规进行评分。Agent-as-a-Judge 方法的可靠性显著优于传统 LLM-as-Judge。但需注意，该方法也面临裁判偏差、评分不一致等挑战。

回归闸门。 在 CI/CD 流水线中设置阈值，当新版本 Agent 在关键指标上低于基准时自动拦截部署，防止质量倒退。

6 环境隔离与工具接口

6.1 沙箱执行的多层次技术栈与工业实践

支架工程要求为每个 Agent 会话提供受控的计算环境，以实现严格的进程、文件系统和网络隔离。这不仅是安全需求，也是确定性的保障——不可信代码的执行不应污染宿主机状态，不同会话之间不得发生数据泄漏。

三种主流隔离技术的对比如下：

从技术演进的角度，2024-2025年间 AI Agent 的沙箱隔离正在从容器向 microVM 全面迁移。Firecracker 和 gVisor 已成为行业主流选择——OpenAI 的 Code Interpreter 基于 gVisor 构建，E2B 的沙箱月创建量从4万飙升至1500万，Anthropic 的 Cowork 则采用 Apple Virtualization.framework 提供完整 VM 级隔离。

Kubernetes Agent Sandbox 原生支持 gVisor 和 Kata Containers 两种安全容器运行时，为将沙箱化 Agent 执行嵌入云原生基础设施提供了标准化方案。Hardening Best Practices 指南指出，沙箱安全需辅以最小权限原则（仅授予任务所需的最小工具集）和数据外泄防护（egress过滤防止数据泄漏）。

6.2 模型上下文协议与工具接口设计

模型上下文协议（MCP）是 Anthropic 于2024年11月推出的开放标准，旨在为 AI 模型与外部工具、数据源之间的连接提供统一的标准化接口。MCP 解决了“M×N 集成税”问题——传统模式下每个 Agent 与每个外部系统之间都需定制集成，随着 Agent 数量 M 和外部系统数量 N 的增长，维护成本呈二次型爆炸。

从工具设计的角度，MCP 实践遵循以下工程原则：

工具设计即 Agent UX。 Agent 通过阅读工具的名称、描述和参数 Schema 来决定是否及如何使用该工具。因此，工具的命名、描述性和 JSON Schema 的严谨性直接影响 Agent 的任务成功率。有风险的注解（如 readOnlyHint、destructiveHint、idempotentHint）被嵌入接口设计中，作为支架层权限决策的输入信号。

代码执行模式以替代多步工具调用。 Anthropic 在2025年11月发表的 MCP 优化指南中提出了解决 Token 膨胀的关键方案：将 MCP 工具转化为“代码 API”，由 Agent 编写并执行代码来批量调用多个工具，仅将最终结果返回模型。实验数据表明，这种方式在处理长时任务时可将 Token 消耗从约150K降低到约2K，节省率高达98.7%。

分层工具暴露与渐进式披露。 与分层上下文系统的设计理念一脉相承，MCP 工具也应遵循“按需加载”原则。不是将所有可用工具在初始化时全量注入上下文，而是仅暴露与当前任务相关的工具子集。

MCP 网关与安全治理。 企业级部署中，所有外部 MCP 调用通常通过 MCP 网关（Gateway）代理，实现认证（如 OAuth 2.1 + mTLS）、授权（如 OPA/Rego 动态策略引擎）、限流和审计追踪。MCP Airlock 是一种零信任安全网关，位于 AI 助手与 MCP 服务器之间，通过 JWT 验证和 OPA/Rego 动态策略决策实现精细化的工具调用管控。MCP 授权规范（2025年6月定稿）进一步以 OAuth 2.1 和 PKCE 为基座，为 Agent 的安全互操作提供了标准化授权框架。

6.3 沙箱与 MCP 的集成模式

在完整的支架工程架构中，代码执行模式和沙箱技术高度耦合。Agent 通过 MCP 工具调用请求代码执行，MCP 服务器将生成的代码部署到沙箱环境中运行（例如 E2B 的 Firecracker microVM 或 Daytona 的 OCI 容器），执行结果被安全地返回给 Agent。这种“MCP 作为接口、沙箱作为运行时”的集成模式构成了支架工程中环境隔离与工具接口两大支柱的统一架构。

7 总结与展望

支架工程标志着 AI Agent 开发从“模型中心”向“系统工程中心”的范式转换。其核心洞见在于：模型能力正在趋同，支架是 Agent 时代的真正护城河。 通过分层上下文管理、计划优先认知流、安全反射与行动闸门的双重防线、全轨迹评估体系以及多层次沙箱隔离，支架工程将非确定性的 LLM 封装在确定性的工程支架中，使 Agent 能够在生产环境中可靠运行。

当前，支架工程面临的主要挑战包括：

• • 工具中立性。 不同 AI 工具之间的指令格式差异使得跨平台支架维护成本高昂。.agents/ 目录配合符号链接的架构已展现出解决这一问题的潜力。
• • 上下文压缩策略的优化。 在超长会话中如何智能摘要历史信息以保持 Agent 的推理质量，仍是活跃的研究领域。
• • 评估量规的标准化。 不同团队和组织定义的评估指标和量规差异仍然较大，缺乏行业统一的基准框架。
• • 安全治理的自动化。 随着 Agent 权限的扩大，如何实现安全策略的自动化生成与自适应调整。

更大的挑战来自架构复合性的提升。随着多智能体协作系统（multi-agent systems）日益增长，如何定义组件间协议、编排并发工作流和跨 Agent 知识共享，正在成为支架工程的核心议题——能力已不再是瓶颈，约束才是。

可以预见，随着智能体能力的进一步演进，支架工程将从当前的“手工打造”阶段逐步走向工程化的组件抽象——标准化的安全闸门模块、可复用的上下文分层模板、跨平台的 Agent 配置协议以及统一的评估基准套件。支架工程正在形成 AI 基础设施领域的新一级学科，其对软件工程方法论的影响将远超提示词工程本身。