让 Context 流动起来：Agent 数字分身如何打通个人工作流与多人协作#

Context 在个人与团队之间流动

写在前面

三个月前我活水到一个新部门，从头 landing。摸熟这套后端系统的过程里，我顺手用 AI Agent 给自己攒了一套工作流：写代码、管项目、跟人同步信息，一段段接了起来。这篇文章讲的就是这套东西怎么长出来的。

先说个具体的。

前几天一个需求刚上完，群里有同事问新增的那张表是干嘛的。搁以前，我得停下手上的活，翻回自己的方案文档，再对着群把字段一个个敲一遍。这次我没动手，只在群里 @ 了我的飞书 Agent，说了句「这个需求是不是开发完了，和大家讲下新增的表的含义和作用」。

它自己接了话。那张授权周期表有哪些字段、每个字段什么意思、写入时守什么规则、离线场景怎么按消息创建时间回看当时的授权，一次讲完。我一个字没复述。

它能讲清楚，是因为这张表的设计、我和同事评审时的每一轮讨论、最后落地的实现，都已沉淀进我的本地工作上下文底座，并同步成它随时可读的 context。我做的只有一件事：把它叫到群里。

这套工作流分三个阶段做起来，每个阶段都是被一个具体痛点推着走的。先搭一个能持续积累的工作上下文底座；有了它，拿它驱动开发和项目管理；个人这侧跑顺之后，再解决怎么把这些资产安全地共享给团队。

💡

第一阶段 · 构建工作上下文底座

这一步最早，比我读到 Karpathy 那条推文还早。我要的不是只收纳既有知识的库，而是一套给 Agent 看、也由 Agent 维护的工作上下文底座：既存已经编译的知识，也承载正在推进的需求、项目状态和协作线索。没有它，后面两个阶段都免谈。

1.1 缘起：编译，而非检索#

2026 年 4 月，Karpathy 发了条题为「LLM Knowledge Bases」的推文，随后用一份 Gist 展开了细节。他说的事正好撞上我当时在瞎摸的方向：每次查询都临时从原始文档里找片段，context 很难积累；Wiki 会由模型持续整理和更新，旧问题的答案也能留下来。

Karpathy 在 Gist 里的原话：The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged.

翻过来就是：交叉引用已经建好了，矛盾已经标出来了，综合分析已经反映了你读过的所有东西。知识编译一次，之后持续更新。

「编译 vs 检索」这个类比很准。RAG 擅长从原始资料里临时找片段，但答案只停在这次查询里时，下一次还得重新找、重新拼。LLM Wiki 会继续把收敛后的内容写回可复用产物。我的工作流保留 RAG 做底层检索，主路径多走一步，把结果编译进 Wiki。下面四个问题，都是我在长期、持续变化的工作 context 里遇到的。

我在这个场景里遇到的问题

实际影响

Chunk 粒度难统一

Vecta 对 50 篇论文做的一次公开 benchmark 里，一套 semantic chunking 配置把平均 chunk 切到 43 token，最终回答准确率为 54%，低于 recursive splitting 的 69%。问题出在过度切碎，43 token 不是语义分块的固定结果。

查询结果很难沉淀

要综合五份文档才能回答的问题，每次都得重新找、重新拼。如果答案没有回写成可复用产物，下次仍要重新走一遍。

多跳检索更容易漏信息

信息分散在多个位置时，召回、排序和上下文组织都要单独治理。Lost in the Middle 也观察到了一个常见现象：关键证据落在长上下文中间时，模型更容易漏掉。

Embedding 迁移有成本

换 embedding 模型时，常常要迁移或重建向量索引；内容持续变化时，也得维护增量更新。这些都能做，只是会成为长期维护成本。

三层：raw sources 不可变，是事实锚点；wiki 归 LLM 写，你只读；schema 就是 AGENTS.md，定义结构和工作流。配 ingest、query、lint 三个操作。这套东西拿来就能用。问题出在我要装的东西上——一整个代码域，三层不够分。

1.2 工作上下文结构#

Karpathy 的三层适合读文章、攒概念。我要装的是一个后端研发日常面对的全部东西：几个代码仓库、跨服务的调用链、业务规则、平台用法、真实需求，还有从需求里长出来的复盘。这些东西的视角不一样。同一个「用户成长体系」，站代码角度看是一堆 struct 和状态机，站业务角度看是一套玩法和规则。硬塞进一个 wiki 目录，很快糊成一锅粥。

所以我把中间那层按视角拆开，最后分成七层。起作用的是每一层只回答一类问题、只守一个稳定边界。分层本身就是给 AI 用的过滤器。

七层各自管什么，现在多大规模：

层与层之间的规矩不多。依赖是单向的，上层引用下层：CASE 往下引 DOMAIN、TOPIC、REPO、Sources，WORK-PROJECT 往下引所有知识层，TOPIC 综合多个 REPO，最后一切都能追到不可变的 Sources。谁也别想把案例写成规则源头。AI 的工作起点也因此从 find . -name “*.go” 变成了 index.md 加分层入口。

代码视角和业务视角是正交的。同一个主题，允许在 REPO/TOPIC 和 DOMAIN 各留一页，用 wikilink 互引。查代码的人和聊业务的人各拿各的那页，不用互相迁就。

最妙的一环是反哺。比如做「自制剧投放测试素材强插」时，我一开始把 material_type 和 business_scene_key 当成这个需求自己的配置。沿调用链查完才发现，它们其实是 story_recommend 承接 UG 素材的一套通用机制。于是项目页只留这次需求的取值和决策，通用的类目映射、召回开关和生效条件回流到 TOPIC/feed/ 的强插能力页。后来再排查其他贴膜需求，直接复用这页，不用重新走一遍代码。

说白了：人先把自己的工作模式编码成目录结构，AI 再按目录找资料。目录已经划清了范围，AI 不用每次都从全部内容里重新判断。

让这套结构生效的是 schema——index.md 总索引加 AGENTS.md 约定。有它，LLM 是个守规矩的 wiki 维护者；没它，就是个漫无目的的聊天机器人。

1.3 自动织网与统一收口#

第一个是自动织网。这是 AI native 知识管理跟传统 wiki 维护拉开差距的地方。举个真事：我用一条指令让 agent 摄入一份飞书妙记，一次 1:1 的录音纪要。它没有只是把内容抄进来，而是把这份妙记按主题拆成 4 个新文件，两份 source 摘要加各自的逐字稿；顺手反向更新了 8 个已有文件——Sources 索引和总索引各增一条，两个相关的历史项目入口页各自在 background 里挂上指向新 source 的 wikilink；所有被改动页面的 frontmatter 时间戳，用实测系统时间统一刷了一遍。

人做这件事，最容易只更新当前页、漏掉反向链接，时间一长整张上下文网就是一堆孤岛。Agent 在明确的 schema 约束下能稳定把这一步做完。每次摄入都让这张网更密一点，而不只是多一个文件。

第二个是工作信息 all-in-one。我把需求项目、知识侧、原始资料统一收口进同一个 vault。解锁点在于：任何一次会话都能随时翻到、引用任意一份页面，把当前 context 里产生的内容沉淀到该去的位置。跨项目、跨知识层的迁移成本被压到接近 0。举个我自己常干的：推进 A 需求时冒出一条跟 A 弱相关、却对某个长期项目有价值的想法，我不切工具、不复制材料，直接 fork 一个新会话，让 agent 参照那个项目的写入规则把想法沉进去。

第二阶段 · 工作流开发驱动

工作上下文底座搭好之后，它就成了我工作流的执行引擎。开发从读 PRD 开始，到把真实项目拆成子任务、编出执行 DAG；每一步的输入和产物都落在同一个 vault 里。

阶段

落下的资料

后续怎么用

需求理解

PRD 原文进入工作上下文底座

后续每一步都能直接引用，不靠我复述

需求澄清

飞书消息记录、妙记逐字稿进入 Sources

把群聊和会议里的口头结论变成 Agent 可见的资料

技术方案

评审收敛后的方案

作为实施拆解、依赖编排和排期的输入

收敛之后自动拆解。以「泛化用户视频偏好众测 H5」的消费链路为例：实施清单覆盖评审、IDL 与 MySQL、通用契约、Provider / Recorder / Builder、单测、监控和联调，按 S0 到 S14 拆成独立任务文档。每页带 status / depends_on / unlocks，并反向链接详细设计；实施计划只镜像状态，任务页才是权威源。

排期这块我踩过一个坑：agent 拆完子任务，会挑顺手的先做，把拓扑依赖忽略掉。于是我在系统 prompt 里强制它动手前先画依赖图，再把纯拓扑升级成「按 Batch（批次）推进 + 关键路径 + 硬门槛」的执行 DAG。下面这张图来自这份消费链路实施计划：15 个执行节点、6 个 Batch、20 条依赖，不是为了说明概念画的玩具图。

图里同时有主实现路径、基础设施分支和质量门槛。主路径从 S0 评审收敛出发，经过 S1 的两天落地、S5 Provider、S6 曝光记录、S7 Builder、S10 单测，到 S13 端到端自测；S2 契约层分出 Manager 和 Pack 两条支线后汇回 Builder，S9 配置汇入单测，S12 监控则是 S13 的另一道门槛。端到端自测通过，才进入 S11 协作方联调。没画图就进不了执行态，「忽略依赖」也就从习惯性失误变成了结构性不可能。

这套流程在几个项目里跑过之后，我让 agent 把它编码成 Dev/规范/ 下的一份强约束规范。这里的写作对象不是人，而是接手实施任务的 Agent：它读取实施计划和子任务页，按依赖认领工作，再把状态、产物和验收证据写回任务页。

2.1 一个小技巧#

上面是主干。真正干活时还有几个具体技巧，权重不高，但确实省事。

先说 Fork 命令。推进一个子任务时，比如那个消费策略 RPC（S8），主 session 里已经装满了 IDL、DAO、model、wire、handler 全栈上下文，还有历次讨论攒下的结论。这时候我用 Fork 起几条副本并行推：一条改 IDL 命名，一条做 DAO 强类型重构，一条跑 wire 生成。副本起步就继承主 session 的全部背景，一句前情提要都不用喂；里面的试错和回退也不会污染主线。说白了就是会话级的 git branch。

再就是主 session 的生命周期。一个横跨十几个子任务、持续好几天的项目，主 session 不是一次性会话。S5 那个把 localcache 改成 anycache 的任务，我第一天 17:38 落了首版，17:56 收到反馈说偏离了设计，留了个 TODO；隔了三天半重启会话，reload 那份任务文档恢复上下文，照着一个现成的范式文件（…/standard/tag.go:26）把替换做完。任务文档是跨 session 的中转介质，会话内存会丢，落到 vault 的任务文档不会丢。context 快到临界点（我一般卡 50%）就主动压一次，再 reload 重新聚焦。

还有实施中的校准。上游会变，决策会改，我把子任务边界当成调整入口。有一次两天内连着做了 5 次校准：上游改 TCC schema、发现底层依赖归属冲突、某批次暂停、算法改成硬编码不走 TCC、发现一条可复用的既有结论。每次校准都只改一个子任务的边界，没有触发全局返工。

第三阶段 · 信息共享与多人协作

到这一步，个人这侧已经跑得挺顺。新痛点冒出来了：这些沉在我本地的信息、过程数据、项目资产，怎么暴露出去让团队里其他人也能用？卡在一个字上——脱敏。我本地的东西是全量真实的，里面有协作方的人名、有 1on1、有决策的反复、有执行层的细节，不能直接外发。为此我做了三件事。

3.1 数据同步与脱敏边界#

暴露资产的前提是脱敏。完整的 WORK-PROJECT/ 始终留在本地，不直接外发；对外只走它的派生目录 WORK-PROJECT-PUBLIC/。它有两条输出：一条是项目 One Page，做人名泛化、过程裁剪和私密链接删除，但保留 TCC key、category_tag、IDL 字段、PSM、资源入口和业务数据；另一条是公开原文，只复制明确标记 public 的 PRD、技术方案和正式评审纪要。现在每一份 Public Markdown 还一对一绑定一个专属飞书 Docx：本地 Public 是权威源，飞书文档是只读分发镜像，飞书 Docx token（文档唯一标识）、revision、正文 hash 和同步时间都写回该文件自己的 frontmatter。正文更新时复用原 Docx token，不重复新建副本。

脱敏做成了一道过不了就卡住的闸门。开发机的工作区只稀疏检出 WORK-PROJECT-PUBLIC/，物理上排除了原始的 WORK-PROJECT、Sources、minutes；每次本地提交前先跑一遍 audit 加 publish，只要审计不过（有未分类、私密泄漏、清单未覆盖），直接停止同步。未标记的默认按私密处理，绝不按文件名放行。脱敏这事靠自觉是靠不住的，得有台机器卡着。

3.2 飞书 Agent 数字分身#

我在开发机上部署了一个飞书 Agent，当我的数字分身。本地的 Obsidian 就是它的数据源，给它供 context。团队协作分两条链路：简单需求直接在群里跟 bot 对话、直接出 MR；复杂需求我在本地推，把 context 同步到开发机，bot 退到幕后，当一个随时能被问到的旁观者。

开头那个「让 bot 给全群讲新增表」的例子，是把 context 搬到协作现场的一次真实运行。现在恢复上下文有三种入口，粒度不一样。

第一种是 /resume。我先在私聊里把某个 session 的上下文加载完整，再到需求群里执行 /resume。群成员接着追问时，Agent 延续的是已经准备好的完整会话，不需要我重新讲背景。

第二种是 Project skill。它不恢复某一次聊天，而是按项目恢复稳定上下文：先从开发机的 WORK-PROJECT-PUBLIC/ 找到项目 One Page，回答业务背景、实现逻辑、公开状态和待确认项；需要核实现行实现时，再用代码做二次验证，并把「项目页记录」和「代码核验」分开说。

人的角色跟着变了：从「写代码 / 写文档」变成「context 装配师」。我的活是把需求上下文在需求群、本地、开发机、bot 之间接好，让它流到该在的位置。执行和答疑交给 agent。

围绕「人和 Agent 在飞书里怎么协作得更好」，我给这个分身做了一批定制，收敛成三条线。

① 减少噪音

长任务的进度用一张会原地更新的交互卡片承载，不刷一屏消息：一轮一卡、终态封口、原子停。判据就一条——最终答案绝不掺进思考流：这条消息还有没有下一个工具调用？有就是过程，可以露；没有就是最终答案，一个字不进进度条。

② 暴露过程价值

把长任务黑箱变成仪表盘：卡片实时显示当前阶段、最近几条进展、已用时、本轮 token 用量，还挂一个能随时中断的「停止处理」按钮。问完问题不用再对着静默的窗口干等。

③ 多人信息同步

一条 /fork 命令，把我本地推出完整上下文的会话原子搬进需求群，群成员带着全部历史接力，授权按「你在不在这个群」判定。遇到要人拍板的决策，弹一张结构化选择卡，谁发起谁回答，还防转发给错的人。

设计主线

具体做法与体感

3.3 协作 skill 与两层 context#

做到这里，我把「信息管理」往上抽了一层，抽到 context 管理。这也是全文的题眼：信息管理的本质就是 context 管理。从建库到工作流到协作，所有动作都是把对的 context 送到对的位置。工具是次要的，关键在 context 存在哪、谁能寻址它。

「分层」这个思路，我最直接的灵感来自 Claude Tag。2026 年 6 月，Anthropic 把 Claude Tag 推到 Slack 团队协作里，让 Claude 以独立身份参与群内任务。最点醒我的一点，是把运行上下文、组织记忆、权限和外部业务状态分开管理。整个团队共用一个巨型 Session 行不通；真正适合共享的是经过治理的事实和产物，聊天上下文仍要守住边界。

Claude Tag 里有几处设计直接影响了我在飞书里的做法。

Claude Tag 的做法

对我的启发

我在飞书 Agent 的实现

Thread 即共享工作 Session：@Claude 在当前 Thread 起一个独立 Session，任何频道成员都能续接、补充、改方向，不限于发起人

协作 Session 该「就地」发生在群里，人人可接力

2 的 /fork：把我本地推出完整上下文的会话原子搬进需求群，群成员带着全部历史接力，授权按「在不在这个群」判定

公开频道沉淀的记忆可在 Workspace 内共享，私有频道和 DM 的记忆留在各自空间；成员可以查看和纠正

跨空间真正要共享的是整理过的稳定事实、决策、约定，原始聊天记录和持续可变的运行上下文都不该共享

3 的两层：原始过程留本地，只把业务状态放进飞书多维表格。那句不变量就是这么来的

主动跟进 + 审计 + 消费治理：支持定时、频道监控、事件触发、主动回帖、可停止、可审计、可配额度

多人 Agent 得能订阅、主动推、可停、可查，不能只是个被动聊天机器人

飞书多维表格的订阅推送（进展 → 群卡片）、审批自动化流程（真实 @ 审批人）、可随时中断的进度卡

一句话总结这份启发，也是我整个协作层的设计原则：共享业务对象，不共享未经治理的巨型 Session；共享确认后的事实和产物，不自动扩散全部聊天上下文。

沿着这条线，我把 context 分成两层，给它们选了不同的存储介质。

我写进协作技能规则里的一条原则：会话里的原始过程留在本地，只有沉淀出的业务状态才共享出去；权限按人分级，每一步操作都留痕可查。

一层是会话私有的过程：一次对话里的原始往来、工具调用轨迹、试到一半的临时假设。它们易变，只对当前这次会话有意义，留在本地（Obsidian 笔记和本地数据库），不外传。另一层是需要共享的业务状态：从过程里蒸馏出来的结论，确认的事实、当前进展、卡在哪、下一步、佐证。这些跨人、跨会话都要复用，才放进飞书多维表格。

为什么选飞书多维表格？同一份业务状态，Agent 能按 case_id、topic_id 幂等写入和回查；团队成员可以直接查看，变更还能自动推送到群里。

选介质有规律：需要人参与、协作、评审、跨人可见的 context 放进飞书多维表格；纯 agent 内部工作记忆（会话消息、长期记忆、内部任务运行）留在本地 SQLite。双可寻址只给需要团队成员查看结构的 context。存储从 agent 私有变成人机共读共写，信息才能在 agent 和团队成员之间同步。

对比 CodeM：我的数字分身与团队级 Agent

把我的飞书 Agent 和 CodeM 放在一起看，表面确实很像：都能在飞书里接任务，也都能连到开发环境，把执行结果带回协作现场。真正拉开两者的，是 Agent 归谁，以及长期 context 属于谁。

CodeM 的产品说明把它定位成团队级研发基础设施：团队统一定义 Agent 的工作方式，执行过程进入飞书项目，可追踪、可介入、可验收。我的飞书 Agent 从我这个人出发。它先承载我的工作记录、判断习惯和项目经验，再按权限读入一部分团队资料。

认知归属

绑定我个人。工作习惯、项目经历、判断偏好和历史对话共同构成它的长期 context。

面向团队研发体系。团队可以统一定义 Agent、Skill、编码规范和工作流。

可读信息

以我的本地工作上下文底座为主，只摄入经过授权的团队资料；对外只发布脱敏结果和共享业务状态。

通过飞书、飞书项目、团队空间和知识库接入组织 context，让任务进入统一流程。

谁在说话

它在群里回答时，延续的是我的个人视角。信息可以来自团队，判断和表达仍有明确 owner。

它按团队配置和流程执行，重点是让任务可追踪、可介入、可验收。

主要价值

替我记住、复述和推进，降低我在跨项目、跨会话、跨协作中的 context 切换成本。

把个人 Coding Agent 纳入团队级生产线，让成功实践被多人复用并持续度量。

维度

我的数字分身

CodeM

所以，我更愿意把群聊中的 Bot 叫作「我的数字分身」。它把我维护的工作上下文投射进飞书；团队成员能看到经治理的结果，也能沿共享业务状态继续协作。它的长期记忆、判断方式和权限边界仍由我维护。前面讲的脱敏、私有过程和共享业务状态，都是为了守住这条边界。

总结

回头看，这三个阶段是一步步长出来的。先让 Agent 有东西可读，再让它能拿这些 context 做事，个人这侧跑顺后，才开始处理它怎么进入团队协作。

第一阶段：让 context 有地方落#

我先把散在代码、文档、群聊和会议里的信息收进同一个工作上下文底座，再用分层目录、index.md 和 AGENTS.md 规定它们该放哪、怎么互相引用。Agent 拿到的是一张会持续更新的 context 网。新资料进来，它会补页面、织链接、回写索引，旧结论也有地方继续长。

第二阶段：让 context 进入执行#

底座搭好后，我把开发流程接了上去。PRD、澄清记录和技术方案继续往下变成任务文档、依赖 DAG、实施状态和验收证据。会话可以中断，子任务可以并行，上游变化也只需校准对应边界。真正跨 session 延续工作的，是落在 vault 里的任务和依赖。

第三阶段：让 context 安全地流向团队#

个人工作流跑顺之后，我开始给共享划边界。完整的 WORK-PROJECT/ 留在本地，经过脱敏和审计的结果进入 WORK-PROJECT-PUBLIC/；原始会话过程继续私有，确认后的业务状态进入飞书多维表格。飞书 Agent 可以代表我参与协作，团队拿到的是可复用、可追踪的结果，它背后的长期记忆和判断方式仍由我维护。

整体总结#

这半年真正发生的变化，是我把原来靠自己记、自己找、自己复述的工作上下文，一点点变成 Agent 可以寻址和操作的工件。工作上下文底座负责积累，开发工作流负责执行，飞书协作层负责把结果送到人面前。三层连起来，数字分身才有了连续性：它承载我的认知，也能把经过治理的结果带进团队。

工具会变，模型会变。我现在最确定的一件事仍然是：把对的 context，在对的时候，送到对的人或 Agent 手里。