写这篇文章的起因，是我最近把自己常用的编码 Agent 从编辑器里真正“搬”了出来——不是换个插件，而是让它以独立进程的方式跑在项目旁边，和我的文件系统、终端、浏览器并行工作。结果发现，原来习惯了编辑器内那种“边聊边改”的体验之后，搬出来最大的问题不是 Agent 本身变笨了，而是我的上下文、任务状态和决策记录全都散掉了。
于是我开始搭建一个本地方向的轻量工作台，把 Agent 的会话、任务、决策和代码变更统一收拢到一个自己完全可控的文件夹里。这篇文章就是围绕“编码 Agent 搬出编辑器之后，本地优先工作台到底在解决什么”展开的，我尽量把动机、踩坑和可复用的搭建路径都写清楚，给同样在折腾 Agent 工作流的同学做一个参考。
1. 从“编辑器内面板”到“独立进程”：Agent 到底经历了什么
1.1 编辑器内 Agent 的巅峰与天花板
说实话，编辑器里的 Agent 体验已经做得很好了。Copilot 的补全、Cursor 的 Tab 补全、各种 Chat 面板，基本上你把需求说清楚，它就能在当前文件附近帮你改代码。这个形态的好处是距离代码最近，上下文天然就是“当前项目 + 当前文件 + 当前选中区”，交互路径最短。
但它也有几个很明显的天花板。
第一是生命周期特别短。编辑器里的一次 Agent 会话，通常只在这个项目窗口存活。你今天聊的需求、定下的方案、Agent 给出的承诺，明天重开编辑器之后就找不到了。除非你主动复制粘贴到笔记里，否则这些信息就是一次性消费品。
第二是并行能力很弱。编辑器面板和你的操作是共享一个 UI 线程的，你不太可能同时开三四个 Agent 让它分头调研、改代码、跑测试。编辑器内它会和你抢鼠标、抢焦点，体验非常“打断”。
第三是它和外部系统基本隔离。编辑器里的 Agent 很难主动去访问你的日历、待办列表、监控面板或者另一个 Agent 的输出。它被限定在了“围绕代码展开”这个舒适区里。
所以当任务从“帮我写一个函数”升级成“帮我做一次跨模块的有计划重构，先调研现状、再出方案、再分步执行、最后跑测试验证”的时候，编辑器内 Agent 就不太够用了。我需要的是一个能独立跑、能长期存在、能被我外部调度的“代理”，而不是一个嵌在编辑器里的“聊天框”。
1.2 搬出去的典型形态：CLI Agent 与后台守护式 Agent
其实“搬出编辑器”这个趋势早就有了。Aider 就是最早一批纯 CLI 的 AI 编程助手，它直接面向 Git 工作流，让 Agent 在终端里读代码、改代码，改完自动提交。后来 Claude Code、Codex CLI 这些工具把交互体验做得更完整，变成了一个可以直接在命令行里对话、也可以批量执行任务的“独立进程”。
这类 Agent 搬出去之后，有几个非常典型的变化：
- 它不再依赖编辑器的窗口状态，而是作为一个进程跑在你的终端、服务器或者后台任务里。你可以用
tmux挂着跑，也可以写一个 daemon 把它拉起来。 - 它的输入输出变成了标准输入输出和文件系统。你给它一个任务描述文件，它可以读完项目结构，直接在文件系统里改代码，然后把变更结果写到日志里。
- 它可以被脚本调用。比如我可以在 CI 里触发一个 Agent 去做代码审查，也可以在收到 Webhook 的时候触发一个 Agent 去处理 issue。这是编辑器内 Agent 做不到的。
- 它可以并行运行多个实例。每个 Agent 实例有独立的会话目录，互不干扰。代价是上下文完全分叉，如果没有外部工作台做协调，很快就是一盘散沙。
我自己实测下来，搬出去之后最舒服的一点是不再被 UI 绑架。我可以在一个终端窗口里专注于看 Agent 的输出，同时在另一个窗口里看代码；Agent 跑它的，我看我的，不用抢焦点。最难受的一点则是“状态管理”几乎归零——它不像编辑器里有项目标签页帮我记住“当前正在做什么”，我得自己想办法把 Agent 的每一步操作、每一个决策、每一段临时输出都记录下来。
1.3 搬出去之后，其实多了一个“黏合层”需求
一旦 Agent 变成独立进程，你立刻就会发现自己和它之间缺了一层东西。
编辑器时代，编辑器本身就是那层东西——它负责展示 Agent 说了什么、改了什么、下一步要做什么。搬出去之后，这一层没了。你如果只是在终端里裸跑 Agent，那么 Agent 完成一轮任务之后，留下的是什么？一堆 git commit？一个 stdout 日志？还是什么都没有？
实际情况往往是：Agent 在跑的过程中会做很多决定，但真正被持久化下来的只有代码变更。它会告诉你“我决定用 X 方案替代 Y 方案，因为 X 的性能更好”，但这句话只出现在终端输出里，翻页之后就没了。如果你第二天想复盘“当时为什么选了 X”，你就得靠记忆。
所以我意识到，搬出去之后必须有一层“黏合层”来承担三件事：
- 持久化 Agent 的决策和推理过程，把这些从“流水输出”变成“可回溯的记录”。
- 统一管理多个 Agent 的任务状态，让它们并行跑的时候不会互相踩脚。
- 提供一个“人要看一眼”的界面，让 Agent 的整体运行状况能被一目了然地把握。
这个黏合层，就是我说的“本地优先工作台”。它不是编辑器，也不是 Agent 本身，而是一个夹在 Agent 和开发者之间的信息管理中枢。
2. 本地优先工作台到底是什么，不是什么
2.1 “本地优先”和“数据存在本地”是两回事
先厘清一个概念。很多人一听“本地优先”，就以为指的是“数据存在自己电脑上”。这当然是一部分，但只说了表面。
“本地优先”（Local-first）的核心主张有三条：
- 数据是首要公民，格式开放。它应该以你能直接读的格式存在（比如 Markdown、SQLite、JSON），而不是锁在某个厂商的私有数据库里。
- 离线可用是默认状态。没有网络的时候，你的工作台应该照常工作。网络只是用来同步和协作的，不是使用的前提。
- 同步是可选的、用户可控的。你可以选择用 Git 同步、用局域网同步、用云盘同步，甚至完全不同步。数据的所有权和最终解释权在你手里，不在平台手里。
放到编码 Agent 工作台的场景下，“本地优先”就意味着：Agent 的会话记录、任务清单、决策日志、代码变更摘要，全都以开放的格式落在你自己掌控的目录里。它不依赖某个在线服务才能读写，也不会因为某个云端产品下线而丢失。
我见过很多团队把 Agent 的日志放到 Notion 或者在线文档里，结果一旦网络不好或者服务商改版，整个记录体系就很被动。本地优先的思路是反过来的：所有东西先在本地生成、本地存储，如果需要分享或协作，再通过 Git 或其它同步手段往外推。
2.2 工作台和笔记软件、任务管理器的边界
那这个“本地优先工作台”和 Obsidian 有什么区别？和 Workbuddy 这类个人工作台工具又有什么区别？
我的理解是：Obsidian 这类工具解决的是“人写笔记、人整理知识”的问题，核心是 Markdown 文件和双向链接。Workbuddy 这类工作台工具解决的是“把工作流、知识库、任务集中到一个可查找的界面”的问题，核心是模块化的工作台框架。而我要说的“编码 Agent 本地优先工作台”，解决的是另一个更窄的问题：让多个自主运行的编码 Agent 在本地留下可读、可查、可回滚的现场记录，并和人的决策过程形成闭环。
它和笔记软件的边界在于：工作台里存的不只是“关于某个话题的想法”，而是“某个 Agent 在某个时间点做了什么事情、产生什么结果、为什么这样做”。它更像是“工程日志”，而不是“知识笔记”。
它和任务管理器的边界在于：工作台里的任务状态不是给人填的，而是和 Agent 的执行状态自动绑定的。Agent 开始跑一个任务，工作台里就多一条“执行中”的记录；Agent 跑完并提交了变更，工作台里就变成“已完成+变更摘要”。人不需要手动去勾选任务状态，工作台只是一个透明化的观察窗口。
2.3 为什么是“工作台”而不是“仪表盘”
也许你会问：那不就是给 Agent 做一个日志仪表盘吗？叫“工作台”是不是有点过度包装？
我理解的区别在于，仪表盘是“用来看”的，工作台是“用来干活的”。
我最早也只是想做仪表盘——把 Agent 的输出汇总到一个网页上看看。但用下来发现，光是“看”不够。我需要：
- 直接在某个 Agent 会话底下追加一条新指令，让它把当前任务的优先级调一下。
- 把 Agent A 的决策记录直接引用到 Agent B 的任务描述里，作为 B 的约束条件。
- 把一个失败的任务连同它的日志打包，作为新任务的“前置材料”重新喂给 Agent。
这就需要工作台不仅要有“读”的界面，还得有“写”的入口。它不应该只是一个状态显示器，而应该是一个可以反向驱动 Agent 的操作面板。
所以我对工作台的定义是：一个本地优先的、可持久化的、既能观察又能驱动的 Agent 操作环境。它以文件夹和开放格式为载体，以脚本和 PWA 为交互界面，把 Agent 从“一次性会话”变成“长期协作对象”。
3. 它真正在解决哪四个具体问题
3.1 上下文归属权：不再被编辑器会话绑架
先说我感受最强烈的一个问题：上下文的生命周期。
在编辑器里，一次 Agent 聊天的上下文默认绑定在会话窗口上。你关掉那个标签页，上下文就没了。你换个分支、重新加载窗口，上下文大概率也没了。就算你复制出来存到笔记里，那也是“你拷贝的副本”，不自动、不完整、不结构化。
把 Agent 搬出去之后，上下文就变成了工作台要管的资产。
我的做法是给每个 Agent 实例建一个独立的工作目录，里面按时间存会话记录（Markdown 格式），并在每次长时间任务启动时生成一份 context.md，汇总当前项目的关键文件路径、约束条件、已定决策。Agent 启动时，我用--context-file或者 prompt 引用的方式把 context.md 喂给它。
这样一来，上下文的所有权和生命周期从“编辑器的某个标签页”转移到了“文件系统里的某个目录”。今天关掉终端，明天继续跑，只要工作台目录还在，上下文就还在。我甚至可以在另一台电脑上克隆同一个目录，Agent 直接接着昨天的进度干活，完全无缝。
这一点对长周期项目的价值是不可估量的。以前我经常遇到“昨天聊的方案今天忘了细节”的情况，现在完全不存在了，因为工作台里每一轮决策都有记录，Agent 自己启动时也会主动去读。
3.2 多 Agent 并行时的协调：共享黑板与任务池
当只有一个 Agent 在干活时，工作台更像一个日志系统。但当多个 Agent 并行跑的时候，工作台就变成了“协调中枢”。
我经常用的场景是分流并行：一个 Agent 负责整体架构调研，输出一份方案；同时另一个 Agent 负责跑现有的代码测试，输出一份基线报告；第三个 Agent 根据前两部分的输出开始实施变更。这三个 Agent 如果各自为战，很容易出现信息不同步的问题——比如 Agent B 不知道 Agent A 已经确认了新的目录结构，于是按旧结构继续写代码。
工作台在这里扮演的是“共享黑板”的角色。我在工作台目录下建了一个shared/子目录，专门放需要多方共享的信息：
shared/spec.md：当前需求的定义和验收标准，任何 Agent 开工前都要读。shared/project-map.yaml：当前项目的目录结构、关键文件位置、模块职责说明。shared/decisions/：已经达成的技术决策，按时间编号。比如001-use-sqlite.md、002-drop-legacy-api.md。
每个 Agent 开工之前，我都会在工作台里给它生成一个 task 描述文件，里面明确写上“开工前先读 shared 目录下的哪些文件”，任务完成后要回来更新 work log。这样多个 Agent 虽然进程是独立的，但它们的信息世界是共享的。
这个模式其实很像多人开发时候的文档规范，只不过现在协作的对象变成了 Agent。没有工作台，多 Agent 协作就是黑箱；有了工作台，每一步都能追溯到“是哪个 Agent、基于什么信息、做了哪个变更”。
3.3 回滚与审计：Agent 乱改代码之后怎么办
搬出编辑器之后，Agent 操作代码的方式也变了。在编辑器里，Agent 的修改是经过编辑器 diff 界面确认的；搬出去之后，很多 CLI Agent 会直接改文件并自动 git commit。这带来了一个审计难题：你并不知道这个 commit 背后的推理过程是什么。
工作台可以在 git 之外补一层“行为审计”。
我要求每个 Agent 在完成一轮任务后，必须生成一个 worklog 文件，内容包括：本轮目标、实际变更文件列表、关键决策点、测试结果、遗留风险。Agent 自己不会主动这么做，所以我用一套脚本在任务结束后自动汇总 stdout 日志和 git diff，生成一个粗糙的 worklog 草稿，再定期由另一个 Agent 把它整理成结构化的记录。
这层审计的价值在“翻车”的时候体现得最明显。有一次一个 Agent 改了一个工具函数，单测过了，但未集成测试覆盖的路径挂了。本地优先工作台让我能很快定位：
- 查看工作台里的 worklog，确认是哪个 Agent 改的。
- 查看 git 提交，找到具体的 diff。
- 查看那次任务记录的“决策点”，发现它因为没有读共享目录里的约束文件，选择了一个和其他模块冲突的重构方式。
如果没有这层记录，这种问题排查会非常痛苦，因为 stdout 日志早就滚没了，你只能靠人肉回忆“当时让谁改的”。有了工作台，回滚和审计都变成了机械操作。
3.4 隐私与所有权：你的代码库上下文不必全部交给云服务
另一个我越来越在意的问题是：当 Agent 需要完整代码库的上下文时，它要把多少东西发给模型服务方？
很多编辑器内 Agent 会把当前项目的文件路径、代码片段、选中内容上传到云端做补全或对话。在项目小、敏感度低的时候还行，但如果你在做一个商业产品、涉及客户数据或核心算法，这个行为本身就有很大风险。
本地优先工作台能让你对“上下文出库”做到精确控制。
我的工作台里维护了一份“出库清单”，也就是 sidecar 文件中明确哪些文件是可以给 Agent 完整读取的，哪些文件只给元信息或者摘要。比如connectors/config/目录下如果有密钥文件，我会在配置里把它列入黑名单；src/core/auth/下的实现，默认只给文件列表和函数签名，不给具体内容，除非手动开白名单。
这种做法在编辑器内会很难受，因为你很难控制编辑器插件到底上传了什么。但搬出来之后，Agent 对文件的访问是受工作台脚本控制的，我可以先走一层“过滤器”再把内容喂给 Agent。这就在不改动 Agent 能力的前提下，给上下文出境加了一道闸。
这算是本地优先带来的一个隐藏红利：因为数据本来就是开放格式、本地存储，所以控制权限完全在自己手里。你可以决定哪一部分给本地模型、哪一部分给云端 API、哪一部分完全不给。
4. 落地路径：一个最小化本地优先工作台的搭建记录
4.1 核心数据模型：直接以 Markdown + Git 为底座
我不建议一开始就去设计一个复杂的数据结构。最实用的起点是：用文件夹当表，用 Markdown 文件当行，用 Git 当数据库。
我的工作台目录长这样：
agent-workspace/ ├── agents/ │ ├── arch-agent/ │ │ ├── profile.md │ │ ├── sessions/ │ │ │ ├── 2025-01-15-01.md │ │ │ └── 2025-01-16-01.md │ │ ├── tasks/ │ │ │ ├── open/ │ │ │ ├── in-progress/ │ │ │ └── done/ │ │ └── worklogs/ │ └── code-review-agent/ ├── shared/ │ ├── spec.md │ ├── project-map.yaml │ └── decisions/ ├── logs/ │ ├── raw-stdout/ │ └── parsed/ └── dashboard/ ├── index.html ├── app.js └── manifest.webmanifest每个 Agent 一个目录，下面分为个人配置、会话、任务、工作日志四块。会话目录按时间存对话摘要和原始输出，任务目录分三态（待办/进行中/已完成），工作日志存放结构化的行为记录。共享目录存放所有 Agent 都要消费的公共上下文。日志目录存原始输出和解析结果。dashboard 目录放一个本地网页前端，用来观看整个工作台。
为什么用 Markdown 而不是 SQLite？两个原因：一是 Markdown 是人和 Agent 都能直接读的格式，你完全可以不用任何工具，直接用 VS Code 打开工作台目录查看记录；二是 Git 对 Markdown 的 diff 支持非常好，每一行变更都能精确追踪。SQLite 适合做查询，但作为日常接触太黑盒了。我的建议是先用 Markdown 跑起来，等数据量大到需要聚合查询时，再写一个脚本把 Markdown 解析进 SQLite，而不是一开始就上数据库。
4.2 与编码 Agent 的对接：让工作台成为 Agent 的“前置上下文”
工作台建好了，怎么让它进入 Agent 的工作流？
我的方案是写一个init-context.js脚本，在每次启动 Agent 之前执行，它会做三件事：
- 扫描
shared/目录下所有文件，生成一个CONTEXT.md汇总文件。 - 读取当前 Agent 目录下的
profile.md和tasks/in-progress/里状态为待执行的 task，把未完成事项追加到 context。 - 把汇总结果输出为格式化文本，然后拼到启动 Agent 的命令参数里。
比如我用 Claude Code 时会这样：
CONTEXT=$(node init-context.js agent=arch-agent) claude --context "$CONTEXT" "继续执行当前任务，开工前先阅读 CONTEXT.md 中的共享规范和待办事项"使用 Codex CLI 时类似：
CONTEXT=$(node init-context.js agent=arch-agent) codex exec --instruction "$CONTEXT"这个“上下文注入”步骤是工作台能真正驱动 Agent 的关键。没有它，工作台只是一个笔记仓库；有了它，工作台就成了 Agent 开工前必读的“项目大脑”。
另外一个实操细节是：不要让每次任务都重新读取全部历史会话，那样又费 token 又容易让 Agent 迷失重点。我的让历史会议记录保持为文件名形式，并通过任务文件夹中列出的“当前任务”条目将其中的部分托管。只有该任务明确引用了某个 session 时，init-context.js才会把它拼进 CONTEXT。
4.3 日志归集与自动分类：不做“数据垃圾桶”
刚开始的时候，我在logs/raw-stdout/里直接丢 Agent 的原始 stdout 重定向文件，比如2025-01-16-arch-agent.log。很快我就发现这不行——原始日志噪音太大，关键决策和普通输出混在一起，找东西要 grep 半天。
后来我写了一个parse-logs.py，做了三层处理：
- 第一层，按行号和时间戳把日志切成“事件块”。Agent 输出的每一个思考步骤、每一个文件操作、每一条命令执行，都变成一个事件。
- 第二层，用简单的关键词规则打标签。比如出现 “decision:”，就归到决策类；出现 “test passed” 或者 “exit code 0”，就归到验证类；出现 “error” 或 “failed”，归到异常类。
- 第三层，把归类好的事件追加到
agents/<name>/worklogs/下对应的日期文件里，并同步更新任务状态。
这一步做完，工作台才真正变成一个可以“回溯真相”的地方。我现在排查问题，基本不去翻原始日志了，直接打开 worklog 里的当天记录，先看“Agent 自己声称做了什么”，再看“实际 git 变更是什么”，最后才去原始日志里找证据。
4.4 加一层 PWA 外壳：什么体验、什么场景真正值得做
搜索结果里有句“给「小小工作台」加上 PWA 能力（manifest + service worker）”，这个点我也试过，但想给还没动手的人泼一点冷水：PWA 不是工作台的核心，它只是让某些场景更方便的一个外壳。
我的工作台跑在一个本地静态服务器上，dashboard 目录本身就是一个纯前端静态页面。加上manifest.webmanifest和一个 service worker 之后，这台机器上的浏览器可以把工作台“安装”成一个应用，支持离线打开。好处是：不用每次开终端，桌面图标点开就是工作台界面，在手机上通过局域网 IP 也能打开查看 Agent 的运行状态。
PWA 里最关键的一个技术点是缓存策略。我的 service worker 只缓存静态资源（html、js、css），对于../agents和../shared目录下的数据请求一律走网络，不做 cache-first。原因很简单：工作台的数据是实时变化的，如果 service worker 把数据也给缓存了，你会看到过期状态。
一个比较轻量的做法是：
self.addEventListener('fetch', event => { const url = new URL(event.request.url); const isApi = url.pathname.startsWith('/data/'); if (isApi) { event.respondWith(fetch(event.request)); } else { event.respondWith( caches.match(event.request).then(cached => cached || fetch(event.request)) ); } });另外，跨设备查看这件事，我的建议是：只在局域网内做，不要为了远程访问去搞复杂的公网映射。手机和电脑在同一个 WiFi 下，打开浏览器输个http://192.168.x.x:8080就够了。隐私方面的风险要小得多。当然，如果有长期远程查看的需求，可以把工作台目录放到一个自己搭建的云服务器上，但这就不是“本地优先”了，除非你用同步工具把它们保持一致。
我把 PWA 当成是“工作台的一个便捷入口”，而不是工作台本身。核心的价值始终在本地文件夹里的数据，PWA 只是让“看一眼数据”这件事更顺手。
4.5 查询与回顾：把散落日志变成周报的三种骚操作
工作台的最大价值在回顾时体现。
我的工作台里每天都会新增好几个 session 文件、worklog、git 提交。我不可能每天全都细看，所以写了一套“聚合回顾”的脚本：
- 日回顾：每天晚上自动跑一次，统计今天哪个 Agent 完成了几个任务、改了几个文件、提交了几次代码、有没有失败记录，合并成一个
daily-summary.md。 - 周回顾：每个周末把 7 个 daily-summary 汇总，提取决策类事件，生成一份
weekly-review.md。我会在这份文件里人工补充一些批注，比如“这周架构变更频繁，下周需要关注稳定性”。 - 跨 Agent 复盘：有时候一个问题涉及多个 Agent 的接力协作，我会写一个小查询脚本，按关键词在 agents 目录下所有 worklog 里搜索，把匹配的事件按时间排序列出。比如搜索“auth service”，就能看到三个 Agent 对同一个模块的历次操作记录。
这三层回顾听起来很简单，但对“总感觉自己工作很忙但不知道忙了啥”的我来说，是实打实地把我从噪声里找信号的时间从半小时压缩到五分钟。
5. 边界与取舍：哪些坑我很明确不建议踩
5.1 轻量任务硬套工作台，反而拖慢效率
我说了这么多工作台的好处，但必须强调一个反向经验：不是所有任务都值得进工作台。
如果你只是改一个 bug、加一个很小的功能，用编辑器里的 Agent 直接跑完，可能 20 分钟就搞定了。如果你这时候还要启动工作台、生成 CONTEXT、跑 log 归集、更新任务状态，那工作台本身带来的开销比 Agent 省下的时间还多。
我的经验是：工作台适合“任务周期超过一天、涉及多文件变更、需要多个 Agent 协作、或者需要事后复盘”的场景。对于几分钟到一小时的临时小改动，让它直接跑在编辑器里，完事拍屁股走人，反而更健康。
也就是说，本地优先工作台和编辑器内 Agent 不是替代关系，而是互补关系。工作台管“工程级任务”，编辑器管“战术级改动”。
5.2 团队成员协作时，本地优先的工作台会碰到什么墙
本地优先这个属性在单人场景下非常舒服，但到了团队协作场景就有摩擦。
比如你想让团队成员看到工作台里的 Agent 任务状态，你不能只扔一个本地目录给他。你需要一个共享的 Git 远程，或者一台共用的服务器。这时候工作台就变成了一个“本地优先 + 远程同步”的混合形态。同步本身没问题，但要注意冲突处理。
尤其是多个 Agent 同时更新同一个worklogs/目录下同一个 agent 的日志文件时，Git 冲突几乎是必然的。解决方式有两种：
- 一是按 Agent 实例拆分子目录，每个 Agent 只写自己的目录，从结构上避免同类文件上的并发写入。
- 二是不要用 Git 实时同步，而是定期 commit + push，通过时间窗口把冲突可能性降到最低。
我在早期踩过“让两个 Agent 同时往同一个 worklog 文件追加内容”的坑，结果 Git 冲突文件长得非常吓人。后来改成“一个 Agent 对应一个独立子目录 + 日志按小时分文件”，冲突就没再出现过了。
5.3 插件生态还非常稀薄，你必须接受自己写胶水
最后要泼的冷水是：这个领域的工具生态还很早期。
你不可能在 GitHub 上找到一个现成的、完美的“编码 Agent 本地优先工作台”，拉下来就能用。你大概率需要自己写以下类型的胶水代码：
- 一个从 Agent stdout 提取结构化事件的小脚本。
- 一个把 CONTEXT 汇总并注入 Agent 启动参数的脚本。
- 一个渲染工作台 dashboard 的静态页面。
- 一个定期把工作台日志 commit 到 Git 的 cron 任务。
这些胶水本身并不复杂，但如果你的目标不是折腾工具而是把活干完，那这些成本就会成为负担。我的建议是：分阶段投入，不要一步到位。先只用文件夹 + 日志重定向跑起来，等觉得“经常要翻日志好痛”的时候再写 parse 脚本；等觉得“多个 Agent 经常信息不同步”的迷茫感浮现时，再引入共享黑板。工作台应该是跟着真实痛点长出来的，而不是照着文章目录抄出来的。
最后分享两个小经验
第一个是“永远不要让工作台成为唯一的信息来源”。本地优先工作台再完善，也只是代码仓库之外的第二层记录。真正的源代码和代码变更历史永远在 Git 里，工作台里的所有决策记录都必须能反查到具体的 commit。定期做一次“工作台 ↔ git 对照检查”，确保日志里写“改了 X 文件 Y 行”的地方，确实能在 git 里找到对应变更，不然工作台会变成自说自话的假历史。
第二个是“保持对工作台本身的维护成本敏感”。它本质上也是一套需要维护的系统。我给自己定的标准是：如果工作台需要我花超过项目本身百分之十几的时间去维护，那就说明设计得太重了，应该回退一步。最理想的本地优先工作台，是那种你几乎感受不到它存在、但每次想找“当时为什么这么做”的时候，它永远能接住你的东西。
