2.5 Agent 看不到关键信息——渐进式披露（Progressive Disclosure）
现象
你把项目文档、代码规范、API 说明、最佳实践……全部塞进 System Prompt。
结果：Agent 的表现反而变差了。
它开始忽略关键规则、做出矛盾的决定、甚至"忘记"你写在最前面的核心要求。
信息越多，Agent 越迷路。
为什么更多信息反而更差？
直觉给 Agent 更多知识 → Agent 更聪明 → 输出更好
现实给 Agent 更多知识 → 关键信息被淹没 → Agent 更困惑
在一页纸上找一句话 → 很快找到。在 1000 页文档中找同一句话 → 可能找不到。文档越大，haystack 越大，needle 越难找。
核心洞察
🔴 关键洞察：更大的上下文窗口 = 更大的 haystack
模型能"看到"更多信息，不代表能"注意到"更多信息。
注意力是有限的资源——上下文越长，每个 token 获得的注意力越稀薄。
解决方案不是"塞更多信息"，而是"在正确的时间展示正确的信息"。
Harness 解决方案
方案一：AGENTS.md 作为"地图"
用一个约 100 行的文件，充当 Agent 的导航地图：
📋 AGENTS.md 示例
markdown
# AGENTS.md — 项目导航
## 可用技能
- [git-ops] Git 操作，遵循 Conventional Commits
- [test-runner] 运行测试，覆盖率门禁 80%
- [deploy] 部署到 staging，需要 PR 审批
## 项目结构
- src/payment/ → 支付模块
- src/order/ → 订单模块
- src/common/ → 公共组件
## 关键规则
- 金额用整数（分），禁止浮点数
- 所有外部调用必须有超时和重试
- 提交前必须通过 Linter + 测试
## 详细文档索引
- 代码规范 → /docs/code-style.md
- API 设计 → /docs/api-guide.md
- 部署流程 → /docs/deploy.mdAgent 先看地图（~100 行），再按需加载详细文档。永远不需要一次看到所有内容。
方案二：Smart Zone 40% 阈值
← 40% 阈值 →超过此线触发 Skill 卸载
40% 是经验阈值——超过这个比例，Agent 开始"顾此失彼"。
方案三：Skills 按需加载
初始上下文中只有 AGENTS.md（~100 行地图）
↓
触发用户说"提交代码" → Harness 识别需要 git-ops 技能
↓
加载加载 git-ops 的 SKILL.md + 激活 MCP 工具
↓
卸载完成后自动卸载，回到 ~100 行状态
对比单体 Prompt 的 2000 行，节省 95%
渐进式披露的三层模型
Level 1
元数据层
始终加载，~50-100 token
"我有哪些能力"（技能名片）
Level 2
详细指令层
按需加载，~200-500 token
"具体怎么做"（技能详细说明）
Level 3
资源层
深度按需
参考文档、模板、示例
Token 节省对比
本节小结
📌 本节核心要点
- 现象：信息越多 Agent 越差——关键信息被淹没在海量上下文中
- 根因：更大的上下文窗口 = 更大的 haystack，注意力被稀释
- 方案：AGENTS.md 地图（~100 行）、Smart Zone 40% 阈值、Skills 按需加载
- 三层模型：元数据层（始终）→ 详细指令层（按需）→ 资源层（深度按需）
- 核心洞察：不是"给更多信息"，而是"在正确的时间展示正确的信息"
思考题
- 你目前的 Agent System Prompt 有多长？如果用渐进式披露重构，你会怎么分层？
- 40% 阈值是经验值。在什么场景下你可能需要调高或调低？依据是什么？
- AGENTS.md 的"地图"思路，和 REST API 的 HATEOAS（超媒体驱动）理念有什么相通之处？
下一节预告
至此，我们分析了 Agent 的五大问题：越界、无反馈、无记忆、执行无结构、信息淹没。下一阶段，我们将这些问题整合成系统化的 Harness 六层架构。