ARTICLE · 1304872
AI agent workspace:我能去哪儿啊,我画地为牢
很多人第一次认真使用 AI Agent，都会经历一种热情澎湃的阶段：
给它配一个精心设计的 System Prompt，划定详细的工作目录，挂载几十个工具，塞进一大堆背景知识，再围绕它建立一套严格的工作规则。然后用着用着…… 就发现它越来越笨了。
它开始生产冗余文件，开始绕弯子，开始磨洋工，开始在任务中途"迷路"，开始重复已经做过的事，开始给出模棱两可甚至前后矛盾的结果。
即使升级模型也无济于事，随着工作时间的累积，token飞速地消耗着，而产出和目标渐行渐远。它好像不再是原来的它了，它被什么东西困住了？
牢笼一：滥用multi-agent过度编排
大多数团队过度使用 sub-agent，一上来就搞 Manager-Worker、Orchestrator + 一堆专家 agent，像复制公司组织架构一样来设计 Agent 系统。
Anthropic 的 客户数据报告中显示:
"带有 skills 的单一 agent 在质量上大多数时候比一次性 prompt 和 sub-agent 两种设计更胜一筹"
“某客户在将多 agent 架构切换为单一 agent 循环后，实现了大约 2 倍的运行速度提升”。
推荐"渐进式披露"的单主循环设计，按需加载 skills 和工具，这一方法使得 Claude Code 的 system prompt 削减了 80% 以上。
过早拆分agent会导致上下文丢失、handoff 错误放大、拼凑出的 system prompt 中的规则冲突、额外的延迟叠加。
适合拆分sub-agent的场景：
确认上下文膨胀确实伤害了单一循环；
任务确实适合在独立上下文中并行运行；
单一 agent 在工具选择和指令冲突上持续挣扎时
牢笼二：工具箱杂乱
Skills 和 tool search 使用渐进式披露：agent 只看到简短描述，在需要时才加载完整内容。
"工具越多越强大"？把一个巨大的、未加区分的工具箱扔给 Agent，它能"自己想清楚用哪个吗"，大概率“不能”。
在部署了 50 个以上 MCP 工具的场景里，工具定义本身就会吃掉约 72K token。并且工具定义在每一轮对话里都会重复出现。也就是说，一次 4 轮对话，光工具定义就烧掉 288K token，成本暴涨高达 400%，同时还会把上下文挤爆。
根据 Anthropic 的 agent 设计指导：工具在大约 30 到 50 个之后工具定义就开始退化。
堆工具还会带来其他隐患：相似工具之间的 schema 混淆会让模型产生幻觉参数；重叠的功能定义引发决策模糊；进而导致规划 token 消耗激增、延迟上升、行为不一致。
适合的工具使用策略：
给 Agent 配备完成任务所需的最小工具集，而不是把它可能"将来用到"的一切都塞进去。
牢笼三： Agent 迷宫
你精心分好 src、docs、temp、archive……层级深、命名"语义清晰"。对人类阅读友好，但对 Agent 却是一座座迷宫。
这是一种极易被忽视的"画地为牢"：你觉得自己在帮 Agent 规划工作空间、梳理路标信息，实际上没有索引和扁平友好结构的"精致目录"只会制造搜索成本和冗余探索文件。
Agent 每次都从零搜索，人类觉得整洁的分类反而让它反复打开错误文件，Agent 把大量能力浪费在了导航上，而不是执行真正的任务。
文件夹结构拖累 agent是因为文件夹是按人类的思维方式组织的，而不是按 agent 的导航方式。
AI agent 需要基于语义和上下文来查找信息，而不是基于文件夹层级结构。Agent 花费大量 token 遍历目录树，只是为了找到它几天甚至几周前创建的文件。
那能怎么解释清楚呢？
解决办法其实很简单——比如在文件夹里写INDEX.md，列出每个子文件夹和重要文件，并说明 agent 应该从哪里开始。有实践者发现，在每个主要文件夹根目录添加一个 index 文件后，原本缓慢的搜索变成了三十秒内的快速读取。
牢笼四：太多的规则
很多人把各种"血泪教训"写成故事式规则、禁止性指令、超详细行为准则，以为越详细越专业。
但在研究实验中证明，在对 100 个流行开源仓库中 AGENTS.md 和 CLAUDE.md 文件的分析中，结果显示配置坏味道（configuration smells）普遍存在。其中 91 个仓库至少存在一种坏味道。
这些坏味道包括：Lint 规则泄漏、上下文臃肿、技能定义泄漏、指令冲突、初始化配置化石化（早已过时却从未更新）、以及指向不存在内容的"盲引用"。
更要命的是长度问题。如果你的 CLAUDE.md 太长，Claude 会忽略一半内容，因为重要规则被淹没在噪音中。Anthropic 的指导建议是每个 CLAUDE.md 文件控制在 200 行以内。
"更长的文件消耗更多上下文并降低遵守度。"
说人话就是：不要太罗嗦，否则agent会左耳进右耳出。
规则过多，等于用人类偏见压缩了模型的探索空间。真正有效的往往是少量原则性表述 + 精确输出格式。
牢笼五：共享空间缺乏边界
多个 agent（或多次运行）共用同一个目录、没有 worktree 或独立 sandbox 时， agent 互相可能同时增删改查同一个文件。这会产生静默的文件覆盖、过时的上下文和 git 锁竞争。两个 agent 针对同一个仓库（甚至不同仓库）运行时如果没有任何隔离，可能互相损坏对方的状态。后果就是它们互相改配置、产生冲突文件、留下大量 temp / build 残留、重复状态文件。
最终让你的工作空间变成一个惨不忍睹的、混乱的垃圾堆。
在不发生冲突的情况下运行多个 agent 的解决方案：Git worktree
给每个 AI agent 一个物理隔离的目录和独立分支，防止文件碰撞和上下文污染。在基础设施层面的硬隔离。
比如 agent-wt 这样的工具就可以将每个 Git worktree 作为 AI agent 的隔离执行沙箱，通过一个 agent 对应一个 worktree 的映射，消除上下文冲突、文件碰撞和分支干扰。
牢笼六：无限上下文
上下文窗口越大越好，能塞多少塞多少？
这种"只要信息多准没错"的想法有个名字，叫"无限上下文谬误"（Infinite Context / more-is-better fallacy）。它是错的。
即使窗口足够大，注意力（attention）也是有限的，失焦的上下文会稀释有效信号，直接拉低输出质量。
研究实证：模型能较好地回忆上下文的开头和结尾，却对中间部分严重丢失。更多上下文 ≠ 更多智慧。
随着任务进行，还会出现一种叫做"上下文腐烂"的现象：随着上下文窗口中 token 数增长，模型准确回忆信息的能力会持续下降（context rot）。上下文窗口必须被视为一种边际收益递减的有限资源，而不是一个可以无限填满的桶。
牢笼七：超长Session
有人习惯在一个超长的对话 Session 里把所有事情都做了，觉得这样 Agent 能"记住前情"，任务更连贯。
在一个长期运行的会话里混合不相关的任务，每完成一个任务都会在窗口里留下"残渣"，这些残渣不断填塞上下文，并在不知不觉中影响当前的决策。就像是每次做饭洗碗都不清空水槽里的残渣，你就会收获一个堵塞的下水道一样。这就是所谓的 "Kitchen Sink Session"。
长会话带来的危险还有：
"目标漂移"：在上下文压缩之后，Agent 可能继续高效地工作，却总是会慢慢跑偏。
某个曾经被明确陈述的约束在摘要中被悄悄丢弃。
最初的指令随着历史增长而逐渐淡出。
Agent 自己不会"发现"自己跑偏了。你不得不一遍遍地纠正它但无济于事。
实践建议是：在大约 50% 的上下文使用量时进行手动压缩，以避免进入"agent 变笨区"。把子任务拆小到足以在 50% 上下文使用量以内完成。
牢笼八：全量输出
为了让 Agent 有尽可能全的信息，有些工作空间设计会把工具调用的完整返回塞进上下文——数据库查询结果、API 响应、原始文件内容，一股脑倒进去。
这时，工具输出在本就有限的上下文窗口中，就会变成是在和系统指令、用户意图、推理步骤争夺空间的存在。
这会即时耗尽上下文窗口限额，损害模型行为。
极端情况下，工具输出本身就能在 Agent 开始处理之前把整个上下文窗口撑爆。
正确做法：从工具响应中只拉取 Agent 真正需要的内容，而不是把完整数据集倾泻进上下文。
牢笼九：人习惯的界面
为人类设计的 Web 界面在数据访问上对 Agent 天然低效。
人类体验为"自然流"的事——点击翻页、在层级菜单中导航；对一个能并行处理大量信息的 AI Agent 来说，却变成了被迫的串行操作。
解决方案是通过创建专为 AI 设计的界面而不是强迫 AI 通过人类界面完成任务，比如使用api接口、命令工具、ai专用浏览器等ai喜欢的交互方式，将 token 消耗降低。
小结：
先让单 Agent 在干净、低噪音、适度自由的环境里把事做成，再按需加复杂结构。 了解哪些行为造成了工作瓶颈，而不是把锅赖在模型不够聪明上。
更精简的工具集、更干净的上下文、更扁平的结构、更短的规则、更清晰的隔离、更聚焦的任务范围。
少即是多。
如果你正在搭建 AI 工作空间，欢迎对照以上清单做一次"减负体检"。先让模型跑起来，再根据真实失败模式迭代，而不是企图用人类"完美架构"让它画地为牢，厉娜
