作为产品, 过去文档是我们的主要知识产物, 尤其在一家被行业内普遍吐槽文档文化比较重的一家公司, 写文档好像是我们的常态。每家互联网公司都把自己的知识产物创作工具做的越来越好, 支持各种文档格式便于大家沟通, 但是在 AI 来之前, 我们好像从来没走近过项目代码那端, 因为除了程序员以外大部分人看不懂也不了解。
我过去很长一段时间都是用 Obsidian + Cursor 这套东西工作。Obsidian 对 AI 非常友好, Cursor 又能干活, 相当于给 Cursor 配了一个长期记忆库, 用着很顺。
但今年开始, 一些 agent 化做得深的 AI 产品已经能直接读懂代码仓库、读懂 Wiki、读懂群聊, 以前必须人手工整理好才能喂给 AI 的东西, 现在 AI 接得过去, 不用人当翻译。
我所在团队以前的流程是运营给产品提需、产品给研发, 文档是必须留档的沟通媒介。现在我自己更多是 AI builder, 直接用 AI 解决大部分事, 那如果是这样, 文档存 Wiki、代码存编译器这件事, 还硬切作为分工, 还说得通吗?
我们的后台也不再是只给人用的, 是同时给 agent 消费的。这件事变了之后, 整套后台怎么搭, 跟我过去做给内部人用的工具完全不是一个思路——harness、skill、prompt、context 这一层怎么组织, 现在得重新设计。
前段时间我让 Agent 帮我回答一个跨好几个系统的真问题——过去某个判断的完整链路是什么, 当时的动机、讨论、决策、上线、结果——它找到了会议纪要、PPT、代码提交、上线指标, 看起来很努力, 但它拼不出那个判断。因为它不知道这四样东西指的是不是同一个。会议纪要里的版本, 可能跟代码里的版本不是一回事; PPT 上的目标, 可能跟最后上线测出来的目标不是同一个; 上线指标的解释, 可能藏在某次没整理进文档的口头对话里。Agent 不是不努力, 是我给它看到的就是四堆东西, 不是同一个东西的四个面。
过去的分工是合理的
组织里的工具分工, 一直是这样的: 代码在 Git, 流程文档在 Wiki, 决策落在会议纪要或 PPT, 商业数据在 Excel, 复盘放在团队群。当时这样分是有道理的——代码那一份只有工程师看得懂, 它要到编译器那一层才有意义; 商业材料给老板, 讲的是数字和取舍; 流程文档给产品和运营, 讲的是规则和例外; 会议纪要给当事人和后续接手的人, 讲的是当时为什么这么决定。每一种载体对应的是一类人, 一类入口, 一套语言。
我们把这些东西分开, 不是因为不会统一, 是因为不同的人本来就不需要看同一个东西。工程师看代码, 业务看 Wiki, 老板看商业材料, 每个人从自己那一份里拿出需要的那一段, 再在脑子里拼起来。拼这件事是人在做, 人脑能处理。
Access 不等于 Context
这一年做的最多的事, 是给 Agent 加 Connector——把 Obsidian、Notion、群聊记录、GitHub 一个一个接过去, 能接的都接了。每个 Connector 解决的都是 Access 问题: Agent 能不能访问到这份资料。但 Access 不等于 Context。
卡住 Agent 的, 是这些资料之间的关系。一段代码引用了一条业务规则, 这条规则写过几版, 现在生效的是哪一版, 谁批准的, 什么时候开始执行, 过去哪些任务用过它, 改它会动到哪些东西——这些信息不是不存在, 而是散在不同系统里, 每一个系统只知道自己那一份。
把这些信息拼起来, 过去一直是人的工作。工程师知道这段代码对应的是哪条业务规则, 因为他们开过那个会; 产品知道那条规则改过几次, 因为他们跟过那个项目; 老板知道为什么最后是这个版本, 因为决策是他拍的。
加 Connector 给的是 Access, Agent 缺的是 Relationship——这些资料之间, 谁引用谁, 谁派生谁, 谁依赖于谁。
Document / Knowledge / Memory / Context / Skill / Action 不是一回事——把当前任务需要的信息装配起来, 是另一回事。
| 概念 | 本质 | 例子 |
|---|---|---|
| Document | 信息载体 | 《招商规则 v2.3.pdf》 |
| Knowledge | 可以复用的认知 | 招商流程必须满足什么条件 |
| Memory | 对历史状态和经历的保存 | 这个客户过去 3 次活动的表现 |
| Context | 当前任务此刻需要知道什么 | 给这个客户做方案需要的规则、历史、状态 |
| Skill | 知道这些以后应该怎么做 | 招商 Agent 的判断流程 |
| Action | 对现实世界产生改变 | 通过、拒绝、提高报价 |
关键区别是: Knowledge 是相对静态的资产, Context 是动态生成的运行时对象。下一代知识系统要解决的问题, 已经从”我的知识存在哪里”, 变成了”谁, 在什么情况下, 应该知道什么”。
Context 装在哪里
Context 是动态生成的, 那装在哪、谁来装。
这件事的活法像搜索引擎又不完全像。搜索引擎接住一个 query, 返回最相关的文档片段, 任务就结束了。Agent 需要的不是”最相关的几段文字”, 而是”在正确时间, 把正确且可信的 Context, 以正确粒度, 提供给正确的 Agent”。
“装配 Context”这一层必须存在。它大致是这样的——拿到一个 Task, 同时知道这是谁在问、问什么、现在做到哪一步、应该知道什么、能知道什么、什么可信、什么过期、什么缺失, 然后把对应的 Knowledge、Memory、State、Tool、Skill 装配成一份当下该用的内容交给 Agent。随着向量数据库、Graph、RAG、长上下文越来越成熟, 存储和召回本身可能逐渐商品化, 装配这一层反而成了真正的瓶颈。
装配需要从一个统一的数据基础里取东西——这个数据基础就是 Context Graph。
┌─────────────────────────────────────────────────────────┐
│ Context Graph │
├─────────────────────────────────────────────────────────┤
│ Intent / Project / Goal / Decision / Knowledge / Rule / SOP │
│ Code / API / Data / Agent / Skill / Prompt / Eval │
│ Trace / Incident / Bad Case / Owner / Version │
│ │
│ Relationship · Dependency · Provenance · State │
└────────────────┬───────────────────┬────────────────────┘
│ │
Build / Change Runtime
│ │
▼ ▼
Code / Agent ────────▶ Execution
▲ │
│ ▼
└─────── Eval / Trace / Incident
│
▼
Context Update
↺
Human ──────── review / decide ────────▶ Agent</pre>
这张图和 Wiki 的区别, 不在装了多少东西, 在每个节点的属性。Wiki 上的条目是被读出来的静态文档; 图里的节点同时有版本、有依赖、有出处、有状态。
拿一条业务规则来想——比如”上海地区必须有本地服务商资质”。在 Wiki 上它只是文档; 在图里它同时是: 当前生效的是 v2.3, 上次改成 v2.3 是因为去年那次客户投诉; 它被代码里某次提交引用; 被 3 个 Agent 调用链用到; 修订由某个负责人批准。每一条”同时是”都需要被记录、被版本化、能反向追溯——这就是图节点和 Wiki 条目的差别。
于是知识第一次开始拥有类似软件工程里那一套——Version、Dependency、Runtime、Scope、Permission、Observability、Provenance、Regression。过去我们把知识当 Content 管理, Agent 时代可能需要开始把知识当 Infrastructure 管理。
AI Coding 加速的不是 Native
我们拥有越来越强的执行 Agent, 却仍然使用为人类设计的文件系统给它提供组织记忆。
过去软件开发最昂贵的部分之一是”把需求变成代码”, 所以”写 Code”是瓶颈。Coding Agent 大幅降低代码生产成本以后, 新的瓶颈开始暴露: AI 不知道为什么要这么写。因为”为什么”散落在 Wiki、PRD、群聊、人的大脑、历史 PR、Git Commit、会议纪要、SOP、Prompt、Skill、Eval、Bad Case、Trace、业务指标——这些地方。AI Coding 加速的是 Implementation, 但真正 AI Native 的系统还必须解决 Intent、Knowledge、Implementation、Runtime 与 Feedback 怎么成为一个连续系统。
于是, 团队今天大量所谓 AI Native 的真实结构其实是:
Wiki / Docs IDE / Git Agent Platform Observability
│ │ │ │
业务知识 代码实现 Prompt / Skill Trace
SOP / 规则 Repo / PR Workflow Eval
决策记录 Test Model Config Bad Case
│ │ │ │
└──────── 人在脑子里连接 ──────────────────────────────┘
↓
AI Coding
每个环节都开始有 AI, 但真正负责把这些东西连接起来的仍然是人的大脑。所以很多所谓 AI Native, 本质只是 AI-accelerated old workflow——AI 加速了一个旧的软件生产体系。
同样, Agent 自进化也不应该简单理解成”Agent 自动改 Prompt”, 而应该是: 系统能够通过 Runtime Feedback 判断 Failure 来自 Model、Knowledge、Context、Skill、Code 还是 Tool, 并修改正确的系统对象, 再经过 Eval 验证后重新进入 Runtime。
我留下的
- 知识的基本单位, 可能会从静态页面变成图里的节点——它有版本、有依赖、有出处, 不再是一篇 Wiki 文章。
- Knowledge 和 Context 不是一回事——静态文档装不下 Agent 需要的运行时上下文。
- Access 不等于 Understanding——加 Connector 给的是 Access, Agent 真正缺的是 Relationship。
- AI Coding 不等于 AI Native Development——Coding Agent 加速的是 Implementation, 但 Intent、Knowledge、Runtime、Feedback 还没连起来。
- Knowledge 要被当 Infrastructure 管, 不是 Content——版本、依赖、出处、回归, 软件工程有的, 知识也要有。
- Human 和 Agent 最终维护的是同一个系统——读、写、Build、Run、Observe、Diagnose、Repair、Learn, 双方一起做。
知识也开始有时钟了。假设上节那条招商规则今天从 v2.3 更新到 v2.4, 系统还必须知道哪些 Agent 在用 v2.3、哪些 Skill 依赖其中某条规则、哪些运行中任务应该立即切换、哪些历史任务必须保留 v2.3、新规则和现有合同是否冲突、谁批准、为什么改、哪些 Eval 应该重跑——知识第一次开始有 Version / Dependency / Runtime / Scope / Permission / Observability / Provenance / Regression 这一套运行时属性, 这件事 Wiki 装不下。
不确定的是 Context Graph 的最终形态——它从哪一侧长出来, 是 Wiki 是 IDE 是 Agent Platform 还是新公司, 我没答案。但有一件事我可以先做: 不调整, Agent 拿到的还是断的上下文。这件事不用等答案, 至少可以从”同一件事的不同面之间, 先建桥开始”——让 Agent 能看到”这是同一件事”, 然后再决定怎么彻底改。
如果你最近也被 Agent 卡在哪件事上, 从你被卡的那个具体场景开始, 看是 Access 不够, 还是 Relationship 缺。