放大的智能体循环：护栏作为加速器

引言

本文结束了自三篇博文以来所展开的系列探讨。 在《看见、行动、修正》一文中，我介绍了将代码代理从“小工具”转变为生产级工具的三大关键杠杆， 并提出了一套网格化框架，用以区分那些能够长期稳定运行的平台投资，以及那些仅能暂时应付的“拐杖式”投入。 在《谁来做什么？——面向代理型平台的团队架构》一文中，我将代理型组织映射到了这一平台架构之上。 而在《将规则固化下来》一文中，赋能团队则将自身的防护机制内嵌于平台之中， 最终悄然消融于平台的运作体系中。

这一路径的逻辑十分清晰：要从个人化的“氛围式编码”（即开发者与大语言模型“互动”）迈向工业化、 大规模的软件工程，平台——以所定义的“平台工程”视角来看，它是一种内部产品， 旨在减轻流式协作团队的认知负担——必须成为代理型劳动力的“指挥家”。

而本文所要解决的问题正是这一点：如今，所有的控制权都集中在交互的起点，而安全网却往往只在最后时刻才发挥作用：

左侧一列代表了当今工具体系的运作方式：初始阶段充满繁重的上下文信息，随后便陷入一片空白， 直到持续集成（CI）的检查门发出“否”的指令。 而蓝色的三条通道，则是本文所设计的三大核心模块：治理、架构上下文，以及在代理型循环的每个环节中由平台所服务的安全保障。

目前已有多种工具覆盖了这一领域的部分功能。NeMo Guardrails通过在输入、对话、执行和输出等环节之间进行强制性约束， 实现了对流程的全面管控。POLARIS（2026年1月）则新增了带有策略编译式保护的类型化规划门。Agentic JWT（2025年9月）提出了一种加密式的动作范围，可将代理行为与用户意图紧密绑定。 这些工具各自聚焦于不同的阶段。然而，真正缺失的——也是2026年5月发布的关于可信代理型人工智能的调查报告明确指出的开放性挑战——正是那套整合性的架构： 在规划阶段实时构建架构上下文，在执行阶段赋予能力令牌，以及在观察阶段提供结构化的意图差距反馈， 将这一切融为一体，形成一个统一的设计体系，让每个环节都能为下一个环节提供更强的支持。 本文提出了一种解决方案；配套的仓库则是一个正在运行的概念验证项目，而非成品。

点击展开

代理型循环：一个提醒 自上一篇博文以来，引擎并未发生任何改变：代理会捕捉意图、规划步骤、通过工具执行操作，并观察结果。当观察结果不理想时，代理会重新规划并不断迭代：整个循环具备自我校正的能力。

这一循环正是现代软件交付的核心引擎。本文接下来要讨论的，始终围绕一个问题：在这一循环中，治理究竟应位于何处？

现状：一切皆预先加载 看看我们如今如何引导代理。治理规则、架构上下文、安全策略——所有这些都在循环启动前被注入，通过最初的提示词和全局指令文件（CLAUDE.md、.cursorrules、copilot-instructions.md、系统提示词）来实现对代理的引导。这些文件构成了业界当前应对引导问题的主流方案，它们有一个共同的特点：一旦启动，便在零点一刻起作用。图中的笔记本标记出这样一个关键节点：初始上下文在“捕获”环节一次性完成组装，而堆栈中提前积累的所有内容，都会汇聚于此。

交互过程呈现出非对称性：所有的控制权都集中在前期。 一旦循环开始运转，代理便只能靠自己。 在规划、执行、观察的每一个环节，都没有人来指引它。 我们编写了两百行指令，然后寄希望于一切顺利。

延迟之门：工作完成后的控制 剩余的控制权往往在最糟糕的时机到来：结束之时。导致持续集成失败的提交被拒绝；被禁止的 API 在代码审查中被标记；不符合规范的颜色被发送至预发布环境，却又被退回。

这些“延迟之门”确实完成了自己的使命——没有破损的代码被推入生产环境，但代价却很高： 代理已经耗尽了其可用的权限令牌。工作已经完成，却不得不重新来过。 每一次回滚，都意味着需要绕行整个循环，再加上一次人为的中断。 这与业界所倡导的“左移测试”（将验证工作尽可能早地推进到交付流程中）背道而驰， 也恰恰让代理本该加速的流程变得愈发令人沮丧。

不过，等等：自我校正难道不正是循环本身的工作吗？ 的确如此。图中红色箭头自第一阶段起，便一直在履行这一职责。 细微之处在于：循环只能纠正其“观察”环节所能看到的内容。 延迟之门是在循环结束后、在代理的观察视野之外作出判断的。 因此，被拒绝的结果无法仅仅作为一次迭代的延续，而是会再次回到起点，以全新的意图出现， 通常由一位感到挫败的人类接手。同样的信息，却在循环边界的一侧被错误地处理。

这种失败源于架构层面，而非技术层面：控制权其实存在，只是位置不对。它处于循环之外，而真正的“循环”却发生在工作进行的环节之中。

转变：将治理内置于循环之中 本文所提出的正是这一转变。与其将一切控制权集中于起点、在终点进行把控，不如让平台将治理内置于循环的每一个环节：

• 在规划阶段，代理在确定策略之前，便已收到架构模式、关键依赖关系以及有效选项； • 在执行阶段，工具本身会承载规则，并实时验证状态； • 在观察阶段，平台会测量结果与原始意图之间的差距，并以结构化的方式将其反馈回代理。 初始上下文又恢复了轻盈的状态：只有意图，除此之外几乎再无其他内容。代理过去用来接收的大量前置文本，如今都得以及时送达，由所需环节直接传递而来。 那么，是谁在打造这样的系统呢？是平台团队——而这正是平台工程学的应有之义：这些机制经过精心设计、版本管理，并作为的内部产品，由流式协作团队及其代理无缝地使用。

支柱一——增强的规划 不要让代理在空洞中进行规划。在代理制定策略的那一刻，平台便会提供企业架构模式、关键依赖关系以及有效选项。

业界对这种指导方式有着专门的术语：黄金之路、铺就的道路、支撑且受祝福的建造之道， 这一概念最早由的Spotify公司推广开来，并由诸如这样的工具加以落地应用。 然而，如今的“黄金之路”更多是为人类而设的文档。 在这里，它们变成了代理的规划输入：不再需要通过阅读数千行代码（甚至更糟的是， 违反这些代码）来发现约定俗成的规则，代理在踏上旅程之前，便已收到了这片地形的地图。

护栏的本质发生了变化：在规划阶段，它会引导代理走向铺就的道路，而不是在最后时刻说“不”。 支柱二——工具内部的上下文执行 平台交给代理的工具（如命令行界面、API、重构脚本）绝不能只是被动的执行器，只返回退出码1和堆栈跟踪。它们必须具备智能：封装业务规则，实时验证状态，当出现问题时，能够以可操作、语义明确的错误来回应。

对比两种不同的体验：被动的工具会这样输出： 复制

而智能的平台工具则会这样输出： 复制

第一个输出会将弱模型送入恐慌循环；第二个输出则将失败转化为即时、有引导的自我校正：工具的表现如同一位确定性的导师。

支柱三——追溯性观察 首先，这一阶段通常会引发这样一个问题：观察的依据究竟来自何处？并非来自侧面渠道；循环并不需要这样的渠道。上下文诞生于“捕获”环节，而不在其他地方。捕获环节正是关键所在：当循环的工作上下文被创建并填充时（即声明的意图、注入的不变条件），后续的每一个环节都会将信息附加到同一个上下文之中：计划、工具调用、原始结果。等到执行到达观察环节时，原始意图仍然停留在它的顶端。图中的上下文芯片正好展示了这一点：观察的依据从捕获的上下文流向比较器，而非从循环外部流入。

支柱三关注的是观察如何运用这一依据。 它不应仅仅为了生成人类可读的日志而存在。 它的职责是测量执行结果与捕获意图之间的差距，并以结构化的方式进行反馈：哪些不变条件被遗漏， 遗漏了多少，又有哪些上下文发生了变化。 而非简单地输出“结果不理想，再试一次”这样的原始信息。

而且，观察本身并不会自动完成意图的达成； 意图差距也不会直接被回溯到规划环节。 内侧的箭头专用于执行层面的错误：工具调用错误，执行失败，于是重新规划步骤（支柱二）。 而意图层面的差距则是完全不同的事情。 它是新的知识（被测量的差距、沿途发现的事实），而知识理应存放在上下文中。 因此，反馈会回到捕获环节，上下文在此处获得这些新元素，循环则在丰富后的上下文中继续完成完整的循环（捕获、 规划、执行、观察），直到差距被缩小，或者预算上的防护机制被触发。 请看图示：绿色的反馈沿着循环本身的路径返回捕获环节，当它抵达时，上下文芯片也随之亮起。 意图通过循环的反复运行得以完成；支柱三只是在每个循环的交汇点上进一步强化了信号。

精确地说，这里并没有发明新的机制；而是将现有的信号引导至正确的回归点。 工具层面的错误会在规划环节重新进入：修复“如何”问题，同样在同一个循环中完成。 意图层面的差距则会在捕获环节重新进入：丰富“什么”内容，开启新的循环。 而第三阶段的延迟之门则不会回到任何地方：它的判断结果完全脱离了循环的视野。 这三者之间的区别不在于箭头本身，而在于信号本身，以及它最终会回到循环中的哪个环节。

（这一支柱还延伸至代理型遥测：通过数以千计的循环执行，衡量护栏的效率，并将其反馈给下一阶段的规划。 这一主题将在未来的文章中得到深入探讨； 而下面的概念验证项目则刻意停留在支柱一和支柱二的范畴内。 ）

愿景：护栏作为加速器 将这三大支柱结合起来，范式已然逆转。平台在每个环节都对代理的假设进行验证，从而赋予其信心（超凡的力量），使其能够安全地执行复杂的修改。结果在循环出口处就已经符合要求：出口处不再设置任何检查门，因为各道关口早已在内部完成了它们的任务。

这也是本文的核心哲学思想：恰当布置的护栏并非制动器，而是加速器。一级方程式赛车之所以能更快地转弯，是因为赛道设有护栏，而赛车拥有牵引力控制系统。若将这些屏障移除，每一圈都将变得更加缓慢、更加谨慎，而非更加自由。 此时，一个合理的质疑或许会浮现：“你刚刚描述的不过是为模型增添的更多支架——这些结构在下一轮模型生成时还能存活吗？”这一质疑值得给出精准的答案，而为此，我们需要一张网格。

两条正交的轴线：持久资产 vs. 支架 在《看见、行动、修正》一文中，我提出了补偿性系统与放大性系统的区别：补偿性系统致力于弥补模型当前的局限性，随着模型不断改进而逐渐失去价值；而放大性系统则依托模型的优势，随着模型的不断进步而不断增值。测试的关键问题在于：如果明天模型的智能提升一倍，这个工具会更有用，还是会毫无用处？ 将这一问题与实施轴线相结合——声明式（文本、简单、脆弱）与程序化（代码、确定性、稳健）——便得到了左侧的网格。不妨把它当作一个决策工具，而非分类体系：在即将构建的工具上，提出两个“×”的疑问，将其归入相应的列，并根据底部的判断结果采取行动（为正确的列提供资金支持；为左侧的列打上标签，并设定一个“日落日期”）。

关键的洞见——也是我在后续设计中最初误判的地方：一个机制是阻断还是引导，并不取决于它究竟是补偿性还是放大性。一份列举了禁止文件的200行提示词，本身就是一种引导，而纯粹是补偿性债务：它与模型对抗，随着模型不断改进而逐渐失效。一个严格的门，用于验证语义不变条件（“模式迁移应先于使用该模式的代码”），则是一种阻断器，同时也是持久的放大器：更智能的模型能够更优雅地满足这些条件，而绝不会让其变得毫无用处。 因此，对于每项平台投资而言，问题从来不是“它是否限制了代理？”而是“它是否能经受住时间的考验？”右下角的单元格（程序化放大器）正是接下来三个章节所立足的领域。

实现支柱一：平台规划门户 这是本文的第一个具体提案。平台规划门户（PPG）通过两项举措拦截规划环节：一项软性举措，一项硬性举措。

软性举措——丰富：在规划前获取适用的规则。想象一下，在开始一项工作之前，与资深架构师进行的十五分钟对话（“在接触支付代码之前，我应该了解些什么？”），并且是自动化完成的。在规划之前，代理会向平台提出同样的问题：它发送自己的意图和仓库上下文，而门户则会以组织的架构决策记录中所提取的架构不变条件作为答案。具体来说： 复制

门户是如何得知ADR-042具有相关性的？每个ADR都会自行声明其范围选择器（此处，“支付”关键词与意图相匹配）：在PoC中进行关键词匹配，在生产环境中进行语义检索。代理将返回的不变条件注入其规划上下文，并基于这些不变条件进行推理：其计划现在包含了在单行代码写入之前的代理步骤。 请注意，rich()特意未完成的两件事。它不执行任何强制性操作：它只是提供建议。强制性操作则在硬性举措中完成。而且，它并未返回任何“配方”（“在第Y行修改X文件”），而是返回了语义不变条件：这些配方正是更好的模型自身所提炼出来的。架构师在ADR中编写不变条件和选择器；门户仅负责提取。正是这种分工，使rich()成为一种声明式放大器：更智能的模型能够更好地利用相同的不变条件。 硬性举措：锁定计划。代理必须将计划转化为结构化的文档（JSON合约，而非纯文本），并提交给平台。门户会运行计划检查器：采用确定性代码，而非大语言模型，秉承像这样的“政策即代码”引擎的精神。不合规的计划会被100%地拒绝，且每次都会以语义违规为特征： 复制

在实践中，代理会自我校正，即使使用小型模型，也只需一两次迭代就能完成：检查器会像编译器一样对其进行修正。 当计划通过时，门户会颁发能力票：一个临时签名的JWT，其中嵌入了计划的指纹以及源自该计划的最小权限范围（哪些文件可以被修改，哪些工具可以被调用）。这正是针对代理型循环所应用的能力型安全机制，也是解锁下一阶段的关键。 实现支柱二：智能工具尊重票证 如果工具不进行检查，这张票证就如同一场戏剧。因此，每款智能平台工具都从相同的三步合同开始： 1. 在工具内部验证票证。代理在执行过程中可能会出现偏差：在飞行途中，代理决定触碰某文件，而此前从未计划过要触碰。工具会解码票证，将请求的操作与锁定的范围进行比对，并以确定性的方式拒绝：OUT_OF_PLAN_SCOPE，既不执行任何操作，也不造成任何损害，更无需清理。这项检查存在于工具内部，因为这是最后一道防线，任何提示词的偏差都无法突破。 2. 在沙盒中执行。先进行干运行，隔离的副本，绝不直接作用于目标。 3. 从语义上进行分析。若失败，工具会返回来自支柱二的结构化、可操作的负载：错误类别、补救指南，以及模型无法预料的上下文（预发布版本的模式、接口定义、被违反的ADR）。 请注意，票证拒绝并非惩罚，且在矩阵手中，它也并非补偿性措施。它直面放大器所面临的对称性风险：未经管控的放大器，会以与成功同等规模放大系统性错误。即便面对完美的模型，最小权限依然至关重要，因为它保护的是组织，而非模型。 治理过渡债务 还有一项缺失的要素，而正是平台团队常常忘记的：对支架的退出计划。 我们刚刚构建的部分，其实是有意识地采用了补偿性策略。之所以会对冻结的遗留文件进行详尽的清点，是因为当今的模型无法可靠地从注释中推断出“已废弃，不可触碰”的含义。之所以会有从原始堆栈跟踪到JSON的转换器，是因为当今的模型更能消化结构化的错误，而非原始错误。随着模型不断改进，这两者终将沦为累赘——当然，只要我们能找到它们。 因此，我们的建议是：将耐用性轴作为每条规则的第一类属性：每一条策略、助推器和转换器都被标记为放大器或补偿性工具，而每件补偿性成果都必须附带可衡量的日落条件（“模型在超过95%的基准测试中，语义上尊重@deprecated”）。平台会公开一份过渡债务报告：补偿性比率，以及待处理的日落清单。这一比率应在模型的各个世代间趋于零：它是平台投资的健康指标。 作为参考，我们曾考虑并放弃的替代方案包括：将所有内容都放入系统提示词中（脆弱、不可验证、补偿性声明式）；仅在持续集成中进行检查（第三阶段的延迟之门：反馈到达得太晚，无法实现自我校正）；使用大语言模型来验证计划（非确定性；我们想要的是检查器，而非法官）。 放大后的循环，已然成型 现在，我们已经将一切安排妥当，完整呈现了整体图景。 意图以轻盈的姿态进入。计划因ADR不变条件而得到丰富，经过确定性检查，并被锁定为能力票。工具在门口验证票证，以沙盒形式执行，并以语义指导来应对失败。观察环节会测量与原始意图之间的差距，并将这些差距反馈回循环。沿途的每一个成果都已在耐用性轴上被标记，而支架也已安排好退出的时间。 结果在循环出口处无需任何检查门流出：这并不是因为控制权被移除，而是因为控制权被重新分配到了工作实际发生的地方。流式协作团队及其代理得以更快地完成任务，因为平台很好地约束了他们。 概念验证 关于代理治理的理念固然廉价，但确定性行为却并非如此。配套的仓库以Go语言端到端实现了支柱一和支柱二：小巧得足以在傍晚读完，却足够完整，可以使用curl运行的完整循环。 代码回答了一个非常明确的问题：代理如何知道该提交哪份计划以进行锁定计划？有三层正交的层次： 模式会以确定性方式验证结构；检查器会以确定性方式验证ADR的合规性；模型则从丰富后的上下文中填充业务内容。这三个层次彼此独立，没有任何重叠。每一步设计决策背后的完整逻辑，都记录在仓库的解释文档中。 规划环节则按照以下顺序执行：从真实的ADR存储中进行丰富（四个带有YAML前言的ADR，其中有一个被刻意标记为补偿性，并附带其日落条件），通过确定性计划检查器，以及JWT能力票： 执行环节则遵循智能工具的合同（工具内部的票证验证、沙盒执行、语义分析）： 代码中有两个值得注意的细节： • 通用的原始→JSON转换器与语义丰富器被分属不同的包，因为它们分别位于矩阵的不同单元格中。当模型天然读取原始堆栈跟踪时，第一个包会被删除，而第二个包则不会受到影响。 • 债务报告有意以DEBT_ALERT的形式发布（五项补偿性成果中，有两项）：这一机制的意义就在于此。 在当今的工具中，它看起来是什么样子？ 这一切都不需要定制化的代理。仓库提供了适配器，可将门户连接到现成的工具：只需几行配置，无需任何分支。 Claude Code，支柱一：基于MCP的规划。门户以标准输入输出的方式暴露出来，作为的MCP服务器，由官方的Go SDK构建，包含两款工具。其中一款命令会注册它： 复制

项目中的CLAUDE.md文件中有一行规定了合同：“在修改任何内容之前，请通过锁定计划提交您的结构化计划。”从此，Claude Code会原生调用get_platform_guidelines_for_intent，接收ADR不变条件，并锁定其计划；若成功，能力票将被保存在项目根目录下的.ppg-ticket文件中。 Claude Code，支柱二：基于钩子的检查。这是我最为满意的部分。Claude Code的PreToolUse钩子，恰好提供了智能工具合同所要求的工具内部拦截点。每当编辑|写入时，都会注册一个ppg守护二进制文件： 复制

钩子会根据票证范围验证目标文件。在范围之内：静默通过。在范围之外：钩子将以代码2退出，阻止工具调用在任何操作执行之前； stderr上的消息会反馈回模型： 复制

代理也会像这样解读这条消息：这是一种确定性的拒绝，也是一种补救路径。在实际会话中，Claude会读取这条消息，要么留在锁定的计划中，要么通过锁定计划返回：循环本身会纠正偏差，正如图11所示。一个现成的代理，在循环中接受治理，无需修改代理的任何一行代码。的适配器说明文档中，详细列出了完整的设置。 GitHub Copilot：黑盒路径。Copilot并未暴露任何循环以供拦截，因此适配器只能退回到预飞行的上下文生成：运行./adapters/preflight “添加Seka支付方式”，调用/enrich，并将不变条件写入的.git/copilot-instructions.md，Copilot会以原生方式读取这些内容，作为仓库的自定义指令。同样的治理方式同样适用于黑盒，仅以声明式的方式实现。诚挚的提醒：如果没有拦截点，硬性检查就无法在循环中进行，只能退回到时间点（平台的预推送检查）。这一差距正是开放循环与封闭循环之间的差异；在选择工具时，这是一个很好的考量标准。 文档遵循和的文档系统（教程、操作指南、参考、解释），因此仓库也同时充当了平台产品的文档模板。PoC若想摆脱PoC身份，需在解释文档中列出所需事项：采用基于嵌入式的ADR检索，而非关键词；KMS背后采用非对称密钥，而非硬编码的密钥；真实地采用写时复制的沙盒；以及完整的观察环节。 如何判断这样的门户是否能在贵组织中发挥作用？我所追踪的成功标准如下： 它在整体格局中的位置 下表将现存的最接近的系统与这三大阶段进行了对应。各列标示了真正的覆盖范围，而非仅仅是理想化的承诺。 底行的两项内容，在任何现有系统中都不存在左侧的列。首先：集成度。前四个系统各自覆盖了一个阶段；真正让治理发挥放大作用，而非仅仅停留在表面的机制，就在于各阶段之间的连贯性：规划上下文塑造了票证，票证约束了工具，工具的语义错误又会重新进入计划。其次：框架设计。现有系统普遍将安全与生产力视为需要权衡的议题。而这里的主张却截然不同：在循环的正确阶段设置护栏，不仅能消除摩擦，反而能减少摩擦，因为代理能够更加自信地行动，少了一些延迟之门带来的意外，也减少了返工次数。可信代理型人工智能调查报告将剩余问题归结为“信任与效用的权衡”；而这里的论点是：这种权衡本质上源于将治理放置在错误的位置，而非治理本身的固有属性。 这仍只是一个概念验证项目。基于关键词的ADR检索，需要在规模化范围内实现基于嵌入式的语义搜索。JWT密钥是对称且硬编码的。沙盒则被模拟出来。支柱3（观察）则明确被排除在外。这些因素并不会否定架构本身；它们只是映射了生产路径。PoC所证明的是：这三大阶段的集成，可以通过现成的组件（Go、JWT、MCP）构建，并且可以与现有代理轻松组合，而无需对它们进行分支改造。 结论 这一系列的主旨，浓缩成一句话：平台是代理型劳动力的指挥家，而它的护栏才是加速器，而非制动器。 前期加载的模型（一堵指令之墙，然后是希望，最后是延迟之门）将代理视为一种需要被约束的对象。而放大后的模型则将代理视为一种需要被装备的对象：规划阶段的地图、工具内部的规则、观察阶段的差距测量。同样的治理，却被重新定位——而这种重新定位彻底改变了这一切：反馈在循环内部到达，却需要一次迭代的成本；反馈在循环之后到达，则会耗费整个循环。 对于正在决定投资方向的平台团队而言，来自的启发法则依然是指南针：当模型智能提升一倍时，这个工具会更有用，还是会毫无用处？为矩阵的右下角单元格（语义不变条件的计划检查器、能力票、语义反馈）提供资金支持，其余部分则标记为支架，并为每一件支架设定一个日落日期。 仍有待探索的第三大支柱：代理型遥测，通过数以千计的循环执行，衡量哪些护栏起到了放大作用，哪些仅仅起到了补偿作用，并将这些数据反馈回ADR存储。这一外层循环的闭环，值得单独撰写一篇文章。 未来的一个小补充：意图不必来自人类。它也可以来自另一名代理——例如，企业架构师代理委托执行子任务，或是平台编排者将更大的计划分解成多个步骤。这一方向正是代理间协议（A2A、AP2）发挥作用的领域；这里所描述的受控循环，将成为受控网格中的一个节点。 让我们在贵组织的机器上，让AI为你工作——而让平台来掌控轨道。