这次，我们先让 Agent 参与了一项具体工作：把一个文章选题从对话里提出来，放进任务表，生成提纲，再继续写成可以审阅的稿件。

做这件事，是因为我们希望把团队任务、采用框架的文章输出和已有资料组织起来。新的想法可以随手记，正在做的事情能看见进度，下一次写作能找到之前的材料。Agent 承担其中的整理和操作，人保留方向判断与审阅责任。

第一版选择 Codex、飞书多维表格和 Obsidian。本篇记录的是这次小范围试跑，以及我们准备怎样继续采用 Agent。

先从一项做得完的工作开始

团队采用 Agent，需要先明确想改善哪项工作、最后交付什么。

这次选的是文章共创。它的输入是一个题目、已有资料和写作要求，输出是一份有来源、能讨论和修改的稿件。题目是否合适、哪些观点代表团队、哪些案例可以使用，需要人来判断；整理资料、建立文件、关联任务和检查链接，则可以交给 Codex。

我们给它的第一条真实指令很短：

新增一个选题：我们团队如何采用 Agent，并建一份 Obsidian 提纲。

Codex 随后在飞书创建选题，在 Obsidian 建立提纲，并把两边关联起来。负责人和日期没有指定，就保持空白。后续说“继续跑完”，任务便继续进入正文整理和交付检查。

对于团队的其他工作，也可以先找这样一个范围清楚的任务：开发者反馈整理、一次实践文档更新，或者一个应用的部署验证。选哪项，要看它是否有真实使用者、能否获得必要资料，以及我们有没有办法判断结果。

固定规则的步骤可以交给脚本；需要结合背景作判断、组合工具并根据结果调整的部分，再让 Agent 参与。工作边界越清楚，人和 Agent 越容易配合。

用现成工具把任务与正文接起来

这次的起步方式参考了 Oil 的个人工作台实践：复用飞书多维表格的界面，让 Agent 通过 CLI 操作同一份数据。我们结合已有的 Obsidian 库，安排了下面的分工。

部分	当前职责
Codex	接收指令，读取背景，整理和生成内容，操作表格并核对结果。
飞书多维表格	保存事项、状态、负责人、计划日期、下一步和笔记位置。
Obsidian	保存来源说明、提纲、正文和操作经验。

飞书使用表格、状态看板和日历三种视图，底层仍是同一张表。正文在 Obsidian 维护，表格保存它的路径和打开入口；笔记也保留返回飞书记录的链接。

我们还建立了一份项目 Skill，记录表格位置、字段含义、笔记目录和操作方式。这样，说“新增选题”或“看看进度”时，Codex 可以直接进入对应资源。操作前仍读取最新字段和记录，避免覆盖人在表格里的修改。

当前这套工作台按对话指令推进。正文仍保存在本机，跨设备笔记同步尚未配置；接入 Grape 自动执行也留到后续需要时再做。

把背景、权限和验收一起交给 Agent

一句话可以发起任务，但要让任务做下去，还需要可读取的背景。

写这篇文章时，Codex 读取了知识库的维护规则、已有提纲、来源笔记和试跑记录。原始资料、整理后的理解和正在写的稿件分开保存，引用具体做法时能找到出处。没有证据支撑的收益、成本和推广效果，继续保留为待补充。

权限也跟着任务安排：创建选题、编辑本地草稿、更新指定状态属于本次工作；正式发布、部署和对外发送，需要各自明确的操作要求。我们希望采用的原则是“规则内自主，越界人工确认”，并在具体任务中写清哪些动作可以继续，哪些动作需要交还给人。

验收则要落到人真正想得到的结果。例如，这次至少要确认：飞书里能找到选题，笔记确实存在，两边指向同一个事项，状态与实际进展相符，入口能定位到目标文章。

一个打不开的链接，暴露了验收遗漏

试跑中遇到过一个很小、也很实际的问题：点击入口后，Obsidian 打开了，却没有定位到那篇提纲。

最初生成链接时，文件名里的空格被编码成了 +。程序把链接解码后，仍能得到预期路径，文件也存在，因此此前的检查认为路径关联正确。

实际应用没有按这个结果打开笔记。我们重新复现：使用旧链接，Obsidian 的活动笔记保持不变；把空格编码改为 %20 后，活动笔记成功切到目标提纲。这也符合 Obsidian 官方 URI 编码要求。

随后，Codex 修正了飞书记录里的入口，并把编码方式和检查要求写回项目 Skill。以后再生成同类链接，可以直接沿用这次修正。

这件事提醒我们，验收要走到实际使用的位置。文件存在、接口返回成功、应用已经唤起，分别证明了不同的事情。用户要的是打开指定文章，就需要核对打开后究竟停在哪篇笔记上。

让人和 Agent 围绕同一份工作记录推进

这次采用的方式是：人给出目标和纠正，Codex 完成操作并留下结果，人继续判断内容和实际体验。

任务状态放在飞书，正文放在 Obsidian。后续处理前先读取最新记录，避免用旧笔记中的状态覆盖表格。到了需要审阅的阶段，把正文和检查结果交出来，状态进入“待人工确认”。

对文章而言，人的审阅重点是：观点能否代表我们，案例是否准确，是否遗漏重要条件，哪些内容适合对外表达。Agent 可以核对资料、链接和记录一致性，但团队最终采用什么说法，仍要有人负责。

其他工作也可以按这个方式安排。先明确目标和交付，再约定背景、操作范围与验收；遇到失败时，留下已完成部分、错误和下一步，便于继续处理或交接。

从这次试跑里留下什么

目前已经留存了选题记录、提纲、正文和核验材料，也修正了一处实际使用中发现的问题。它说明这条内容工作流能够继续往下走。多人是否愿意持续使用、是否减少等待和返工，还需要后续任务给出证据。

接下来，可以让同事用这份工作台处理一个新选题，观察是否能找到所需背景、理解当前进度，并接着修改稿件。是否把独立接手纳入正式验收，仍待团队确认。

同时开始记录完整投入：从提出选题到可审阅稿件用了多久，人花了多少时间补充资料、复核和返工，模型与工具花费多少，后续维护需要什么。当前这些基线和成本数据均待补充。

我们会根据这些结果决定继续扩大、调整做法，还是停下某项尝试。被验证有效的部分，可以整理为任务模板、Skill 和知识笔记，供下一次工作使用。Karpathy 的 LLM Wiki 提供了持续维护知识的思路；本次先落实来源保留、过程记录和经验回写，后续再按实际需要扩展。

对我们来说，采用 Agent 的第一步已经足够具体：让它参与一项真实工作，把交付和验收接起来，再把有效做法交给下一位同事。