Agent Native

GitHub: Approaching-AI/meta-agent

Agent 的能力已经够强了。

用了半年 coding agent，这是我最大的感受。agent 完不成任务的时候，很少是因为它不会，几乎都是因为它不知道。公司内部的项目背景、客户的具体需求、某个设计决策背后的考量，这些从未出现在训练集中的信息，模型没有理由知道。

问题出在上下文。

上下文的带宽瓶颈

人类往 agent 里灌上下文的方式，本质上是打字。带宽就那么大。更要命的是，人类往往意识不到自己有多少隐含知识没有传达。你觉得"这不是显然的吗"，但 agent 不知道。你愿意写，持续同步的代价也很大。谁会在写完代码之后再花同样的时间写文档？

所以一个项目跑了一段时间再引入 agent，agent 面对的是一个巨大的上下文缺口。它不知道之前发生了什么，不知道为什么这段代码写成这样，不知道哪些路已经走过了走不通。效果很难好。

但如果从 Day 0 就用 agent，情况完全不同。Agent 每次工作时自己记录前因后果，上下文就会随项目自然积累。每次 session 多记一点，成本均摊到日常工作中，比事后补齐轻松得多。

这是 Agent Native 的核心：从一开始就按 agent 能理解的方式工作。

Agent = 上下文体 + 运行时

在这套方法论里，agent 被拆成两个部分。

上下文体是静态的，就是一个 git 仓库。项目代码、工作日志、知识文档、操作流程，全在里面。它可以交接，可以持久化，可以做版本管理。Session 是短暂的，但上下文体是持久的。

运行时是动态的，就是任意一个 coding agent 加上背后的大模型。Claude Code、Cursor、Windsurf，都行。运行时在上下文体之上启动，读取信息，执行任务，把成果写回去。

上下文体是通用的，运行时可以换。你今天用 Claude Code，明天换别的，上下文体不受影响。方法论不绑定任何框架或模型。

大多数关于 agent 的讨论集中在运行时：哪个模型更强、哪个框架更好、prompt 怎么写更有效。但在实践中，运行时的差异越来越小。真正决定 agent 工作质量的是上下文体的丰富程度。

三个核心组件

上下文体里有三类东西：daily notes、doc 和 handoff。

Daily notes

每次 session 的发现、决策、进展，都记在 daily notes 里。这是上下文积累的主要手段。

两个原则：append-only，不改历史记录；要更正就显式标注，不要静默修改。和 git commit 一个道理，历史是不可变的，修正是新的事件。

Daily notes 不是文档。不需要写得漂亮，不需要结构完整，就是工作记录。觉得有东西值得记就立刻写进去，不要等到 session 结束。一方面防丢，一方面释放上下文空间。很多 coding agent 有 compact（压缩上下文）功能，但 compact 要为压缩预留一部分上下文窗口。不如直接写文件，既持久化了信息，又腾出了空间。

Doc

Doc 是对项目某个方面的认知快照，放在 doc/ 目录下。来源不限：agent 的总结、人写的文档、外部参考资料都行。

Daily notes 是增量的，一条一条往上加。Doc 是全量的，代表某个时间点对某件事的整体理解。两者互补。

Doc 里有一种特殊的形式：SOP（标准操作流程）。SOP 从 daily notes 的实践中提炼而来，每个 SOP 包含起始条件、结束条件、执行步骤。SOP 和脚本的区别在于执行者。脚本是死的，遇到异常就挂。SOP 由 agent 执行，agent 能处理过程中的意外，网络不通就换代理，磁盘满了就清理空间。SOP 的创建由人决定，agent 可以建议。不是所有重复的事情都值得变成 SOP，这个判断需要人来做。

Handoff

每个 agent session 都是短暂的，上下文窗口有限，一次对话终究会结束。但项目是持续的。Handoff 就是解决 session 间连续性的机制。

Handoff 文件就是一个 prompt，纯文本，放在 handoff/ 目录下。内容只需要指明方向：做什么、从哪里继续、有什么坑。它是一个指针，不是一份文档。后续 agent 在同一个上下文体上启动，能访问所有 daily notes、doc 和代码，不需要重复已有的上下文。

Handoff 本质上是一种异步的 agent 间通信。它不假设下一个 session 用的是同一个模型、同一个框架，甚至同一个人。只要运行时能读文件、能理解自然语言，接力就能继续。

信息的流动

三个组件各司其职，之间有自然的信息流。

Daily notes 积累原始的实践经验。某个问题撞了好几次之后，从 daily notes 里提炼出 SOP，沉淀到 doc 中。Doc 也独立积累，来源不限，随时可以写。Handoff 驱动 session 间的连续性，确保未完成的工作不会丢失在上下文窗口的边界上。

这形成了一个完整的工作循环。每个 session 开始时，检查有没有上一个 session 留下的 handoff 文件，有就接着干，没有就等用户指令。工作过程中，随时把发现和决策写入 daily notes。结束时，总结写入 daily notes，commit 并 push 确保持久化，然后判断是否需要生成 handoff 给下一个 session。

Session 启动，读取上下文，执行任务，记录结果，交接。每一轮都让上下文体更丰富一点。传统的 best practice 写出来之后很快就过时，因为维护成本高。而这里的信息沉淀由 agent 在工作中自然完成，成本均摊到每次 session，几乎感觉不到。

内部协作与外部协作

传统的工作交接需要写文档、开会、讲前因后果。本质上都是在传递 context，效率很低。

但不是所有协作都需要传递上下文。什么是"内部协作"，什么是"外部协作"？

界定标准是上下文体的边界。共享同一个上下文体的人和 agent，就是内部协作；跨上下文体的交互，就是外部协作。内部协作的本质是传递上下文，而外部协作至少是 context-small 的。交付一个产品、收付一笔款项、签一份合同，这些交互不需要对方理解你内部的前因后果。外部协作交换的是结果，不是过程。

Context-free 是一个相对概念，取决于交互双方是否需要额外上下文才能理解。Bash 怎么用，对今天的大模型来说就是 context-free 的，训练集里有足够的知识，不需要你解释。但你公司的部署流程不是，你客户的验收标准不是，甚至"这笔钱该不该花"对模型来说也不是。所以内部和外部的边界，本质上是由交互所需的上下文量来定义的。上下文量趋近于零就是外部协作，需要大量上下文就是内部协作。

Agent Native 真正改变的是内部协作。交接就是把上下文体交出去。接手的人跑一个 agent session，agent 去读 daily notes 和 doc，回答任何问题。大部分信息已经在记录里了，不需要额外同步。实际项目中，一个月的 agent 驱动工作可以积累近百篇 daily notes，多份 doc（包括二十多个 SOP）。新的协作者对着这个上下文体启动 agent，几分钟就能了解项目全貌。传统方式需要多少个会？

开放问题

这套方法论还有没解决的问题。最大的一个是多 agent 协作。

当一个项目的上下文体大到单个 agent 吃不下，怎么拆分？拆分之后多个 agent 之间怎么协作？上下文体之间的依赖关系怎么管理？

目前没有好的答案。但方向是清楚的：agent 之间最大的区别是它们的上下文体不同。理解了这一点，协作问题就变成了上下文体的分治问题。

还有上下文体的生命周期管理。Daily notes 会越来越多，不是所有历史记录都同等重要。什么时候归档、怎么压缩、哪些信息该沉淀到 doc 里，还需要更多实践来回答。