Agent 物理约束
一句话定义
Agent 有两个不可消除的物理约束（不是 bug，像光速一样）：上下文容量（context 是有限的容器）+ 注意力带宽（同时处理多个任务时注意力是零和的）。
出处
@yan5xu《最近一些 Agent 认知：OS 与 Agent-native 应用》(2026-03-17)。
两个约束详解
约束 1：上下文容量
Context 是有限的容器，塞得越多性能越差。
- 模型的 context window 即便扩到 1M / 10M token，仍然有边际效应
- 塞太多无关上下文会稀释推理质量
- 这是物理约束，不是工程问题——增加 context 不等于增加能力
约束 2：注意力带宽
Agent 同时处理多个任务时，注意力是零和的——就像周伯通双手互搏，左手画圆右手画方，合在一起两个都变形了。
- 多任务并行 = 注意力被切分
- 每个任务都做不到最优
- 这是 transformer 架构的内在性质
三个使用场景
- 判断产品是否真的 Agent-native：如果 Agent 上下文无限大、注意力完美，这个产品还有存在理由吗？没有 = 它是真的在解决物理约束。
- 诊断”超能力 Agent”叙事红灯：声称”一个 Agent 搞定所有事”的产品 = 否认物理约束 = 红灯。
- 设计产品功能边界：把无关上下文搬到外部、把注意力卸载到专业模块——这是 Agent-native 设计的真正切入点。
反例 / 边界
- ❌ “Context 越大越好” — 否认上下文容量约束
- ❌ “一个全能 Agent” — 否认注意力带宽约束
- ✅ “我们把 [领域] 推理搬到外部，让 Agent 注意力释放” — 真 Agent-native
典型案例
- ✅ Case - InsForge - Agent原生数据库 — 把数据持久化推理搬到外部
- ✅ Case - Composio - AI Agent工具集成平台 — 把工具调用推理外化
相关术语
- 认知卸载与能力解锁 — 解决两个约束对应的两类价值
- 认知共生 — App 释放 Agent 注意力，形成飞轮
- Agent-native 壁垒 — 解决物理约束就是建立壁垒
- Skill 天花板 — Skill 没有解决物理约束，只是接口封装