Substrate-Aware AI Agents：执行上下文作为 Agent 规划的第一等输入

  • 关联论文：2609.05232
  • 作者：Tom
  • 更新：2026-09-07

一句话结论

告诉 LLM Agent 可用 RAM 和执行时间上限，Agent 会主动把代码从"大内存、长时间"重构为"省资源、快速"——无需改变任务目标，仅靠披露执行契约就能诱导出结构性自适应代码。

解决什么真问题

当前 LLM Agent 在规划时，只拿到"任务描述"，完全不知道目标机器的内存、算力、时间预算等物理约束。这种 Substrate Blindness（基质盲） 导致 Agent 生成在理论上正确、但在实际部署环境中无法运行的代码（如无限申请内存、O(n²) 算法处理大数据）。

现有研究要么让 Agent 猜测资源，要么靠编译器报错后再修。两者都低效且不可预测。

本文的核心问题是：如果把执行上下文（RAM 限制、wall-time 上限）显式告知 Agent，Agent 能否自主做出结构性代码适配？

核心方法

核心概念：Substrate Blindness

作者将 Agent 选择行动时缺乏执行上下文信息的状态定义为 substrate blindness——Agent 在真空中做规划，选择"最大通用"的实现，而不考虑部署环境的资源边界。

实验设计

实验在数值计算任务（高维成对欧氏距离计算）上展开，具有以下关键特性： - 实现选择和操作后果可直接观测（peak memory / wall time） - 资源消耗可精确量化 - 代码质量有明确对错（输出正确性 + 资源合规）

测试了三种前沿模型配置： - Anthropic Claude Opus 5 - OpenAI GPT-5.6-Sol - Google Gemini 3.7 Flash

每组两个条件对比： - Task-only：只给任务描述 - Contract-disclosed：任务描述 + 128 MB RAM + 10.0 s wall-time 合同

关键数据

第一轮（128 MB / 10.0 s 合同）： - 13/14 对比中，披露合同降低了实测峰值内存 - 所有三组均降低了平均 wall time - 执行速度提升最高 3.1 倍

第二轮（更严格：96 MB 合同）：

模型 Task-only 正确率 Contract-disclosed 正确率
Claude Opus 5 0/5 4/5
GPT-5.6-Sol 1/5 5/5
Gemini 3.7 Flash 0/5 3/5

三组平均 MaxRSS 和 wall time 均比 task-only 降低 49-74% 和 35-64%。

代码结构变化（合同诱导）： - 有界阻塞（bounded blocking） - float32 保留（而非 float64） - 上三角遍历（upper-triangle traversal） - 原地或 memory-mapped buffers

机制分析

作者通过代码审计发现，披露合同后 Agent 自发引入了结构性修改（不是修 bug，而是换算法/数据结构），说明 Agent 理解并内化了资源约束，将其纳入了规划空间。

关键实验与数据

  1. 受控对比设计：同一任务 × 两种上下文条件 × 三个模型 × 多次采样，最大化可比性
  2. 量化指标：Peak MaxRSS（内存）+ wall time（时间）+ correctness（功能正确性）
  3. 两阶段合同梯度：128 MB（宽松）→ 96 MB（紧张），测试 Agent 在更严约束下的适应能力
  4. 代码审计：手工分析合同披露组的代码，发现结构性变化而非微调
  5. 开源：GitHub manu2/Context-Aware-Agent-Experiment

亮点与局限

亮点： - 问题定义清晰：substrate blindness 是一个被忽视但普遍的 Agent 规划缺陷 - 干预极简：只需在 prompt 里加一行资源约束，无需工具调用、编译器反馈或额外训练 - 效果显著：某些场景从 0/5 变 5/5，证明结构性适应是真实的 - 可复现：代码已开源，有完整的实验 artifact

局限： - 任务域有限：只在数值代码生成上验证，尚不清楚迁移到复杂规划/工具使用任务是否成立 - Agent 模型版本：GPT-5.6-Sol 命名较新（2026 年时间线），模型名称可能代表未来版本，结论的时效性需确认 - 合同格式未标准化：128 MB / 10.0 s 是人工设定，真实系统里如何自动生成"合理合同"未探讨 - 无消融分析：不清楚是哪一种约束（内存 vs 时间）驱动了代码改变，或两者等效 - Under review：论文尚未经过正式同行评审，方法论细节（如代码审计的系统性）无法充分核验

对工程落地的启发

  1. LLM Agent 部署时加一行 context：在 mission prompt 里写 "可用资源：最多 512 MB RAM，单次调用不超过 5s"——成本极低，值得一试
  2. 合同驱动自适应：对于需要长时间运行的 agent 任务（代码生成、数据处理），可以先跑宽松合同探测，再收紧，让 Agent 自己选合适的实现路径
  3. 对编译器反馈环的补充：传统做法是"生成 → 超时 → 报错 → 重生成"，本文证明"前置告知"可以把这个环提前到生成之前，减少迭代次数
  4. 多模型横向对比价值：发现 Claude Opus 5 在资源约束下最稳定（4/5 vs 0/5），GPT-5.6-Sol 最适应（5/5），这对生产环境模型选型有直接参考意义

与同方向工作的关系

  • 与 Toolformer / ReAct 的区别：Toolformer 等研究关注"工具选择"，本文关注"资源约束下的实现选择"——同一任务可以有不同的工具/算法实现，本文证明了上下文约束能引导实现质量
  • 与 RL-based Agent 资源优化：无需强化学习训一个专门节省资源的 Agent，仅靠 prompt 工程就诱导出结构性适应
  • 与 System-aware LLM 研究：LLM compiler tuning、hardware-aware code generation 等方向需要额外训练或微调，本文是纯 zero-shot 干预
  • 与这篇文章互补：Memory-Augmented Agent（记忆增强）关注内部状态管理；本文关注外部执行基质的感知——两个方向可以正交叠加

适合谁读

  • Agent 系统工程师：关心生产环境 LLM Agent 稳定性的实践者，直接可用的轻量干预
  • LLM 应用研究者：理解 substrate blindness 作为规划缺陷的框架，可以启发新的评估维度
  • Prompt 工程师：掌握"告知资源约束"这一低成本高回报的 prompt 技巧
  • 模型评估研究者：为 LLM Agent 评测增加"资源感知"维度，避免只看正确性忽略资源效率

⚠️ 说明：本文尚未经过正式同行评审（8 页篇幅，under review），方法论细节和代码审计的系统性依赖作者自述，开源 artifact 提供了部分可复现性。