Harness Engineering：AI智能体系统化架构方法论30篇精选

摘要

支架工程（Harness Engineering）是一门正在兴起的架构学科，它的目标很明确：为AI智能体（Agent）搭建一个高度结构化的“运行环境”——也就是支架。这个支架不是简单的容器，而是一个精密设计的系统，包含了上下文交付、工具接口、规划工件、验证循环、记忆管理和沙箱执行等一整套机制。其核心目的，就是让智能体在处理真实任务时，变得更高效、更安全、也更可靠。

和传统的AI开发思路不太一样，支架工程不把宝全押在提升模型能力上。它认为，很多时候智能体表现不佳，瓶颈不在模型本身，而在于它周围的环境——上下文质量够不够好、约束机制够不够硬、反馈回路够不够快。说到“支架”（Harness），它本身就是一个很形象的隐喻。就骑马来说吧：模型是马，上下文是它看到的视野，而支架，就是那副缰绳、马鞍和路。本文会系统地梳理一下支架工程的理论框架和技术实现，重点围绕分层上下文系统、计划优先工作流、安全反射与行动闸门、评估支架、沙箱隔离与工具接口这五大核心支柱展开讨论，分析它们的设计原则、关键技术和理论背景，并结合最新的学术研究和产业实践，来聊聊它未来的可能。

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

1 引言

我们先来定个调：什么是AI智能体？简单说，就是“由语言模型驱动，能在多次迭代中规划并执行动作，以实现复杂目标的实体”。这几年，智能体的能力边界确实在快速拓展，已经能在真实世界里完成像编码、调试、部署、数据分析这样多步骤的任务了。但能力上去了，新问题也跟着来了：多步执行中容易错误累积、上下文信息衰减、安全越界……这些问题的根子，往往不在模型本身，而是它身处的那个运行环境设计得有问题。

在这种背景下，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、注意力池化和强化学习驱动的策略来平衡局部和全局信号，在很多任务上都改善了性能和记忆效率。还有Context-Focus Window Mechanism，它搞了个指针式的外部记忆例程，把超出上下文限制的工具输出存到键值运行时库里，Agent只接收一个轻量指针，在多步化学工作流中，Token消耗能减少大约7倍。Tree of Agents（TOA）则另辟蹊径，采用多智能体推理框架，把输入切成小块交给独立的Agent去处理，通过动态信息交换沿着树结构路径进行多视角协同推理，用紧凑型LLaMA3.1-8B驱动时，在多种长上下文任务上，性能甚至能跟更大的商业模型掰掰手腕。

但支架工程的分层上下文系统，切入角度有点不一样。与其费劲去扩展上下文窗口、或者压缩信息，不如换个思路：把上下文看作一种分级缓存机制——精确控制在不同任务阶段，到底喂多少信息给模型。这个设计的灵感，其实是从计算机体系结构里的缓存层级设计（L1/L2/L3 Cache）借来的，在工程实践中，就形成了从全局“宪法”到按需加载的模块文档这样一个完整层次。

2.2 分层架构的具体设计

这个分层上下文系统，从顶层到底层，依次是这样的：

第一层：根规则文件（代码库“宪法”）。通常叫AGENTS.md或者CLAUDE.md。CLAUDE.md有个特点：它是唯一一个默认进入每一次Agent对话的文件，所以它里面的每条指令都消耗Token预算，但同时也享有最高的注意力权重。正因为这样，宪法层里只应该放那些“Agent无法通过读代码自己推导出来的部落知识”——比如非直观的架构规则、多租户隔离准则、版本隔离策略、项目独有的编码禁令等等。那些通用的编码建议、或者已经内化在模型训练数据里的知识，就别放这儿了。

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执行嵌入云原生基础设施，提供了标准化的方案。在安全方面，沙箱安全需要辅以最小权限原则（只授予任务所需的最小工具集）和数据外泄防护（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基础设施领域的一个新一级学科，它对软件工程方法论的影响，将远远超出提示词工程本身。