在人工智能代理系统的演进历程中，大多数架构遵循相对保守的设计范式：预先定义工具集、固定行为模式、通过外部编排层调度能力。然而，一类新兴的实验性项目正在打破这一范式 —— 它们允许代理在运行时修改自身的代码与行为逻辑，实现能力的自主演进。Hollow 正是这一思路的典型代表，它展示了一种完全不同于传统编排型代理与技能框架型代理的架构路径。
传统代理架构的局限性
当前主流的代理系统可以划分为两大类别。第一类是基于编排的模拟代理（Sim Agent），如行业常见的 Agentic Workflow 系统，通过预定义的任务分解逻辑与状态机来协调多个子任务执行。这类系统的优势在于行为可预测、易于调试，但代价是能力上限被束缚在预先设计的编排逻辑之内。第二类是技能框架型代理（Skills-based Agent），典型代表如 Superpowers 与 Browserbase，它们将特定能力封装为可插拔的技能模块，运行时动态加载以扩展代理的功能边界。这两类架构的共同特征是：代理本身的行为逻辑在初始化时确定，运行时仅能调用预先注册的外部工具或技能，无法触及自身的核心代码。
这种设计在面对长尾场景时暴露出明显的不足。当代理遇到编排图中未覆盖的分支条件时，只能返回失败或求助人工介入；当新任务需要前所未有的能力时，必须由开发者在外部扩展技能库。这种 “代理即工具” 的定位虽然保障了系统稳定性，却也制约了代理的自主性与适应性。
运行时自修改架构的核心要素
自修改代理系统的设计理念是将代理自身的代码视为可变的执行时资源，而非静态的编译产物。Hollow 所代表的架构路径包含三个核心工程要素：代码生成器、动态加载器与版本控制系统。
代码生成器是自修改架构的发动机。与传统代理调用外部 API 不同，自修改代理在面对新任务时，首先分析任务需求，随后生成或修改自身的核心逻辑代码。这一过程通常依托大型语言模型的代码生成能力实现。代理会根据当前任务上下文、历史执行反馈与可用工具描述，自主编写或改进函数实现、调整控制流逻辑、甚至引入新的数据结构。这一步骤的工程挑战在于：生成的代码必须满足语法正确性要求，且在语义上与现有代码库兼容。
动态加载器负责将生成的代码注入到运行时的代理上下文中。常见的实现策略包括 Python 的 importlib.reload 模块热重载机制、进程内的脚本引擎（如 Lua、Python 解释器嵌入），或容器级别的服务滚动更新。动态加载器需要处理的关键技术点包括：内存中旧代码的清理与新代码的替换、已打开的资源句柄迁移、并发执行的请求如何在代码切换期间保持一致性。对于生产级系统而言，热重载的原子性与失败回滚能力是决定系统可用性的关键因素。
版本控制系统在自修改架构中承担着安全阀的角色。由于代理可以自主修改自身代码，修改历史必须被完整记录，以便在出现问题时快速回退。这一机制借鉴了版本控制领域的成熟实践：每次代码变更生成一个新的快照，包含变更的时间戳、触发上下文、执行结果与差异对比。当新代码导致运行时异常或行为偏离预期时，系统可以自动或半自动地回滚到上一个稳定版本。
安全防护与可靠性保障
运行时自修改能力带来的工程风险不容忽视。代码生成依赖大型语言模型，而模型的输出并非总是可靠 —— 生成的代码可能包含语法错误、逻辑缺陷，甚至引入安全隐患。Hollow 架构需要在以下几个层面建立防护机制。
沙箱隔离是第一道防线。自修改代理生成的代码不应直接在宿主进程中执行，而应在隔离的沙箱环境中运行。常见的隔离方案包括：容器级进程隔离（每个代理实例运行在独立的容器中）、虚拟机级别的强隔离、或进程内的语言级沙箱（如 Python 的 RestrictedPython）。隔离的目的是确保恶意或有缺陷的代码无法直接访问宿主系统的敏感资源。
增量验证机制可以在代码生效前捕获潜在问题。代理在执行自修改之前，可以先将生成的代码在影子模式（Shadow Mode）下运行若干测试用例，通过单元测试或回归测试验证代码的基本正确性。通过设置测试覆盖率阈值与关键断言通过率，可以有效降低有缺陷代码进入生产环境的概率。
速率限制与人工审批是另一层保护。自修改能力不应是无限制的 —— 系统应当对单位时间内的修改次数进行上限约束，并在关键场景下触发人工审批流程。例如，当代理尝试修改涉及财务计算、安全认证或数据访问的核心逻辑时，系统可以暂停自动执行并通知运维人员介入审核。
实践参数与监控要点
在工程实现层面，构建自修改代理系统需要关注以下可操作参数与监控指标。代码生成层面，建议设置最大单次生成 token 数为 4096、生成超时阈值为 30 秒、并发生成任务数上限为 2，以控制资源消耗。动态加载层面，热重载间隔建议不低于 10 秒（避免频繁切换导致的状态不一致）、重载失败时的默认策略设置为回滚而非继续执行。版本管理层面，版本保留数量建议设为 20 个快照（对应约 200 次修改操作）、自动回滚触发条件为连续 3 次执行失败或响应延迟超过阈值。
监控指标应当覆盖代码变更频率（反映代理的适应活跃度）、代码回滚率（反映生成质量）、执行成功率在修改前后的对比（反映修改的有效性）、以及沙箱资源消耗（防止资源泄漏）。这些指标的异常波动往往预示着代理行为的失控或外部环境的变化，需要及时告警与人工介入。
与现有架构的协同可能
自修改代理并非要完全取代编排型或技能框架型系统。相反，三者可以形成互补的层次结构。在底层，技能框架提供稳定的工具能力集，代理可以调用这些预封装的能力而不必重新生成；在中层，编排逻辑定义宏观的任务分解策略，引导代理在正确的方向上进行自我改进；在顶层，自修改机制赋予代理突破预定义边界的灵活性，应对编排图中未覆盖的长尾场景。
这种分层协作的关键在于接口契约的标准化。技能框架需要暴露清晰的函数签名与能力描述，供代理在代码生成时引用；编排层需要支持动态注册新的子任务路径，而非仅限于静态图；自修改层需要提供受控的代码边界，防止代理跨越权限边界修改不应触及的系统组件。
Hollow 所代表的运行时自修改架构目前仍处于实验阶段，其工程可靠性与安全性有待更多生产环境的验证。然而，这一方向揭示了代理系统演进的一种可能性：从 “被设计的工具” 向 “能够自我进化的实体” 转变。这一转变带来的不仅是技术层面的挑战，更涉及对代理自主性边界的哲学思考。对于工程实践者而言，理解自修改架构的核心设计模式、评估其适用场景与风险边界，比盲目追逐新范式更为重要。
资料来源：本文关于运行时代码生成与自修改代理架构的技术细节参考了 Self-modifying code 的 Wikipedia 条目以及相关的开源实现实践。