来源信息

  • 文档类型：阅读笔记 · 整理日期 2026-10-07
  • 原文：《Seeing like an agent》 · 作者 Thariq Shihipar · 发布于 claude.dev · 发布日期 2026-04-10
  • 原文地址：https://claude.dev/blog/seeing-like-an-agent/
  • 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。

阅读范围

  • 全文，覆盖提问工具三次尝试、任务演进、搜索接口、Guide 代理与结语。

工具要适配能力

通用工具与大量专用工具之间没有固定最优解。接口需匹配模型能力、目标和环境，观察调用轨迹再调整。

提问工具经历三次设计：将问题附在退出规划工具上，会让计划与待答问题相互冲突；解析特殊 Markdown 又不够稳定；独立的结构化提问工具才让模型能在合适时机提问，并提供可选答案与明确交互界面。

从清单到任务

早期 Todo 配合周期提醒帮助保持目标，后来反而可能让模型不愿修改计划。Task 引入依赖与共享更新，服务于代理协作。旧工具曾经有效，不代表新模型仍需要同样的限制。

搜索与渐进披露

文章描述从预索引 RAG 向主动搜索代码的探索：索引有速度优势，也有环境与维护负担；搜索工具让代理自己建立相关上下文。Skills 通过文件引用逐层发现信息，扩展能力未必需要新增工具。

Claude Code Guide 的例子更进一步：直接给文档入口会把大量资料带进主上下文；专门的子代理负责搜索和提炼，只返回所需答案。作者也承认这仍可能混淆，需不断实验。

适用限制

这是特定产品的演化经验，不能据此判定 RAG 过时、结构化提问总比文本好，或工具越少越好。文中的模型表现与工具数量属于当时状态。本文未运行网页工具、改配置或创建代理；接口可调用性、返回信息质量与最终任务成功要分别检验。

游戏开发应用建议

以下为整理者建议，非原文实测，也不表示已经实施。

设计 NPC 工具时，可先区分查询状态、提出动作和执行动作。查询返回资源标识、占用者、状态版本与失败原因；执行检查前置条件，避免模型仅凭自然语言推断资源仍可用。复杂动作需考虑重复调用和被打断后的恢复。

玩法尚未决定时，先询问影响架构的关键选择，再形成计划。无需把所有美术偏好一次问完，问题应有明确决策用途。参考查询可独立提炼，但回传需保留出处与不确定性，方便主任务核对。

可用正常、缺资源、状态过期和无效目标等场景观察模型如何选工具、是否反复误用、能否理解错误返回，再决定拆分或合并接口。不能只看 schema 合法；实际世界状态是否正确更关键。模型升级后重跑这些场景，检查原来为防错添加的限制是否仍有帮助。

小结

工具设计应从真实调用和失败中迭代，让模型获得合适的信息与动作空间，同时保留明确的状态和执行边界。

参考来源

相关笔记