智能体工作区令牌经济

接口形状决定了智能体的令牌账单

同一个模型、同一份数据、同一个任务，仅仅因为工作区的呈现方式不同，令牌消耗就可能相差 45%。很多团队把降本重点放在模型选型和提示词优化上，却忽略了真正的成本杠杆：数据、工具和产物是如何暴露给智能体的。

典型症状很具体：智能体回答简单问题前，先花大量轮次探索 schema；工具调用链动辄超过 5 步；日志和 blob 被整段塞进上下文；换一个接口，同样的问题成本翻倍。

核心机制：文件系统语义与渐进披露

LLM 在 shell、Unix 工具、Git 和代码导航语料上受过大量训练，最稳定的行为模式是渐进披露：先低成本发现，再定点读取，然后范围化搜索，最后引用证据。

技能据此总结了文件系统语义的四根支柱：

• 路径即句柄：/runs/abc/stdout.log 同时是名称和地址，智能体可以回到证据而不必重建上下文
• 范围化搜索：全局 grep 用于发现，目录级 grep 用于提取，减少无关上下文注入
• 行号：天然的审计轨迹，便于校验和引用
• 下推操作：在一次调用中完成过滤、排序、limit 和投影，减少对话轮次

关键架构建议是两层模型：不要拿文件替代数据库，而是在现有存储之上叠加一层工作区命名空间。底层继续做它擅长的事，顶层给智能体一个它能高效导航的接口。

什么时候用，什么时候别用

决策规则很明确：清晰的聚合查询和排行榜场景，关系型接口更合适；而「找 cohort → 查日志 → 引用证据」这类复合探索任务，命名空间接口能赢 2–3 倍。

注意三类反模式：schema 优先探索强迫智能体读完整个 schema 才能行动；blob 急切加载把整段日志拉进上下文，实际只需要三行；扁平工具命名空间把几百个工具堆在一个列表里，没有层次。此外还要警惕 ID 间接寻址链和依赖上文的上下文耦合。

设计完成后，可用清单自查：能否用一次低成本调用发现数据？路径在跨会话间是否稳定？搜索能否限定范围？结果是否带行号？过滤与投影能否下推？