Agent 的四层工作边界：越用越乱，问题不在模型

来源：抖音视频 · 一只桌子（桌子的频道 · 从 ChatBot 到 Agent 第四期）· 约 5 分钟 · 作品 ID 7685681479640272180

作者烧了 40 多亿 token 后的结论：Agent 用久了最容易出问题的不是模型能力，而是工作边界没划清。四层边界从外到内是 —— ① Project（项目文件夹 = 办公室，放规则和工具）② Chat（对话 = 今天桌面上的工单，别拖太长、及时交接）③ Subagent / 外派（脏活杂活留在外面，只带结论回来）④ Worktree（多方案并行时一人一个沙盒）。

他还分享了两个常驻 Skill：交接 Skill（提醒你什么时候该换对话 + 自动整理状态并开新对话接手）和网页替身 WEB_OFFLOAD（把又重又吃推理的调研活派给 ChatGPT 网页端跑，只把结论带回 Codex）。

和 018（把原理图做成 MD 给 AI 读）、020（Codex 斜杠命令） 是同一条线上的三个点：018 解决「AI 不知道板子长什么样」，020 解决「命令不会用」，这条解决「活往哪儿塞」。

0. 四层总览

此处配图暂缺，参阅原帖。

作者的开头原话：两个常驻 Skill 看起来解决的是两个不同问题，但它们其实都指向同一件事——Agent 的工作边界。一个对话到底该用多久？什么时候开新项目？什么活适合丢给子 Agent？什么时候需要 Worktree？

1. 第一层 Project：门禁卡 ≠ 办公室

此处配图暂缺，参阅原帖。

新手常问：既然给了 Agent 完全访问权限，它哪里都能去，为什么还要特意建一个项目文件夹？

作者的回答：如果只是短任务、一次性任务或者闲聊，确实没必要；但当你真正做一系列事情或一个完整项目时，文件夹的重要性就出来了。

打个比方：完全访问 = 你有整栋楼的门禁卡（解决「它能不能去」）；项目文件夹 = 一间固定办公室（解决「这件长期工作有没有固定的规则和工具」）。

它最重要的意义是搞定两件事：

1. 沉淀项目经验——AGENTS.md、视频分镜规范、字幕规范、踩坑记录写在项目文件夹里，换任何新对话进来，Agent 读一遍这些文件就能直接上手；
2. 固定工作环境——比如他的 Remotion 工程、项目级 Skill、素材处理脚本、依赖配置全在里面，下次开新对话进来，工具全摆在桌上，直接拿起来就能开始干活。

2. 第二层 Chat：一个对话别拖太长

此处配图暂缺，参阅原帖。

如果项目文件夹是办公室，那对话就是今天摆在桌面上的工单。大家都知道的活分开聊，容易忽略的是：同一件事也别在一个对话里拖得太长。

很多人觉得现在模型支持 100 万上下文是标配，长了还会自动压缩。作者的原话：自动压缩前一两轮还好，多压几轮就压得面目全非了，后面任务出错概率直线上升。

所以：与其让一个对话反复压缩硬撑下去，不如及时做好交接。

但交接有两个很烦的地方：一是自己不会一直想着交接这回事，聊嗨了根本没想到，等做事开始漂移才反应过来；二是直接换新对话，它根本不知道你前面干了什么，你又得当打字员从头交代一遍。

常驻 Skill 之一：交接 Skill

此处配图暂缺，参阅原帖。

它做的事：在需要做交接的时候主动提醒你换对话（防止聊过头）→ 你确认后自动把「干完了什么、敲定了什么规矩、下一步从哪里开始」整理好 → 并且自己开一个新对话发送相关指令，直接无缝接着干。

画面里 PROJECT_STATE.md 的真实字段（OCR 整理）：接手任务编号 / 当前交接状态（待接手 → 已接手） / 当前目标 / 当前未验证项 / 本次约束（未录屏、未修改业务文件、未扩大范围）/ 给下一棒的指令。

此处配图暂缺，参阅原帖。

画面里还有一句很关键的约束，值得原样抄进你自己的项目：

请只更新 PROJECT_STATE.md 中的「交接状态」为「已接手」，然后回读该字段确认。不要修改其他内容。

3. 第三层 Subagent：值得抄的是「上下文隔离」

此处配图暂缺，参阅原帖。

很多人看到多 Agent 觉得很酷炫，但作者现实干活中很少用，主要是因为太烧 token。不过——

不是说子 Agent 不好用，而是子 Agent 的思路很值得借鉴。子 Agent 最核心的价值其实就四个字：上下文隔离。派小弟去外面翻五万字的垃圾资料，把脏活杂活留在外面，最后只把提炼好的结论带回主工程。

常驻 Skill 之二：网页替身 WEB_OFFLOAD

此处配图暂缺，参阅原帖。

作者声称 ChatGPT 网页端和 Codex 端的用量分开，客户端存在连接通道，并据此做了自动化分流；这些说法受产品、套餐、版本和接口影响，本笔记没有验证为通用事实：

凡是遇到资料搜索、调研、长文分析、翻对比这种又重又吃推理的独立子任务，自动交给网页端跑；网页端在它自己的独立额度里分析推理，跑完写下 [WEB_OFFLOAD_DONE]，把精炼的结论带回来给 Codex。

画面里那份提示词的几条要求（OCR 整理，这几条很值得抄）：

• 只查一次现有浏览器状态，避免覆盖已有草稿（先检查再动手）；
• 基于各厂商官方文档，查不到的明确标注，不用社区材料补齐；
• 每家给出「方向推断」2–4 句，但必须标明是推断，不能冒充官方表述；
• 横向选型结论按场景给 1–3 家并简述依据，不做排名；
• 最后列「证据边界」：核对日期、无法确认的项目、版本变化。

（这个 Skill 是作者针对 Codex 设计的，他自己说：如果用的是别的 Agent，也可以按这个思路自己去改。）

4. 第四层 Worktree：对话分开了，工作目录还没分开

此处配图暂缺，参阅原帖。

开几个不同对话，只是把任务上下文分开了；可如果这几个对话最后都去改同一个项目文件夹里的文件，还是很容易互相覆盖、互相干扰。

Worktree 就相当于你给每个对话单独复制一份项目，让他们各改各的，最后把最好的结果合并回来。

什么时候才需要开：多个对话、多个方案，同时改一个 Git 项目的时候。 作者原话——只是一个对话按顺序干活，完全没有必要开 Worktree。

5. 一张决策表

此处配图暂缺，参阅原帖。

6. 我补的提醒与落地建议

此处配图暂缺，参阅原帖。

• 前提绑定具体产品：网页替身靠的是「ChatGPT 网页端与 Codex 端额度分离 + 官方客户端两端通道」。换别的产品这套不一定成立，能抄的是思路（把重活派出去、只带结论回来）。
• Worktree 是 Git 的功能，不是对话功能。没有版本管理的项目先上 Git，再谈并行沙盒。
• 「40 多亿 token」是作者自己的用量，不是通用门槛，别拿它当衡量标准。
• 交接要落成文件，别只靠对话：和 018 的 `mcu_pin.md`、020 的 `AGENTS.md` 是同一招——把「每次都要重讲的东西」写进文件，让 AI 自己读。
• 对你的落地：给电赛工程建一个 PROJECT_STATE.md（当前进度 / 已定接口 / 已验证项 / 待验证项 / 下一步），每次换对话先让它读这个文件再开工。
• 最小起步：先只做两件事——项目根建 AGENTS.md；长任务中途做一次交接。这两步成本最低、收益最快。