知识管理这件事，过去更多是“文库”和“经验萃取”的话术，如今在顶级咨询公司那里，已经被翻译成一个更尖锐的问题：当我们开始认真做 Agent 时，怎么把几十年的行业 know‑how、项目资产和人才梯队，变成一个可被智能体持续调用和进化的“活系统”？
最近被问到很多咨询公司有关于开发Agent，以及如何对知识进行有效管理的问题。这里给出我们结合我们思考的几个建议。
一、从“知识库”到“上下文系统”
如果用这篇 Agent 设计文章里的话来说，LLM 的上下文窗口，本质上是一个昂贵又极其有限的“注意力预算”。 咨询公司的痛点刚好卡在这儿：你真正想喂给模型的，是几十年项目、无数交付物、访谈纪要、专家判断；但模型一次能认真“看”的，其实只有很薄的一层。
这意味着，传统 KM 的几个默认前提正在失效：
- “多”不再是美德，信息堆得越多，越不可能直接进上下文。
- “静态分类”价值有限，你再精细的知识树，也不等于模型可以自然使用。
- “文档即知识”的假设需要被打破，知识要被重新拆成可以在上下文里编排的行动单元。
换句话说，所谓“给咨询公司做 Agent”，其实不是给 ChatGPT 多接几个 API，而是要重新设计：什么应该常驻上下文，什么写进文件系统，什么变成可调用的“技能”，什么干脆交给人来决策。
二、给咨询公司的 Agent 一台“项目电脑”
优秀的 Agent，往往都有一台属于自己的“计算机”：带文件系统、带 shell，可以读写长期状态，而不只是一条长对话。
放在咨询场景里，这个计算机抽象非常自然：
文件系统：对应你的项目资产
历史 proposal、交付 PPT、model、访谈纪要、研究报告。可以按“项目 / 客户 / 行业 / 议题”组织成结构化目录，而不是一锅粥塞进向量库。
CLI：对应你的方法工具箱
比如：市场容量测算脚本、估值模型、客户调研问卷模板、访谈大纲生成器。
Agent 不必记住“如何做 DCF”，而是学会调用 run_dcf_model，再围绕结果做推理。
这和很多人做“咨询 Agent”时的直觉完全相反：大家第一反应是“我要把所有 PPT 喂给模型”；但现实更像是：你要先给它一个整洁的项目工作空间，然后再让它在这个空间里“像 consultant 一样工作”。
对 Junior 的意义也很直接；他不再是从一个巨大知识库里“找文档”，而是可以看到一个 Agent 怎样在这个“项目电脑”上，从零搭建一个交付：新建文件夹、复制模板、写计划、拉数据、更新假设、产出初稿。这个过程，比任何 onboarding 手册都更具教学价值。
三、重新理解“过往项目经验”的沉淀方式
放在咨询公司里，它们分别对应两个层面的 KM 设计。卸载上下文：把项目过程写进“可被重放”的轨迹。不是只存结果 PPT，而是：
- 决策过程：关键假设如何形成、哪几个选项被否掉、为什么。
- 迭代轨迹：从 v0 到 vFinal 之间，都发生了什么调整。
这些内容不必常驻模型上下文，而是写入文件或“项目日志”，在后续类似项目中按需读回。
演化上下文：让方法论和“套路”在 token 空间里长出来。
可以有一个定期运行的“反思 Agent”，去回顾过去一段时间的项目日志：识别哪些套路反复出现（例如“市场进入分析”的固定三步）。
把这些抽象成“技能文件”（对应文中的 SKILL.md、技能标准）。
对 Junior 来说，这就变成了一套不断更新的“战术手册”，而不是十年前 PPT 模板的简单翻版。
关键在于：项目经验不等于“多一个标签的文档”，而是要被拆分成可以被 Agent 稳定调用和组合的“程序 +样例 + 反思”。这也解释了为什么单纯上一个向量库，往往很难真正改变学习曲线——你只是把图书馆数字化了，但没有重写“怎么用这些书”的逻辑。
四、Junior 的学习曲线：从“看答案”到“看过程”
咨询顾问的传统优势之一是learning curve，学习曲线。对于未来的Junior，我们认为所需要的技能包可能要更新下了。
一个可以想象的设计是这样的：对每个新入职的咨询顾问，维护一套“个人工作空间”。
包含他参与的项目、他写过的 deck、Mentor 的评语、错题本式的案例。
有一个“教学 Agent”定期回顾这些轨迹，帮他：抽取他擅长和薄弱的模块，比如结构化能力强但行业知识薄弱。
推荐下一步学习材料和项目任务，不是泛泛而谈，而是“你在上个 case 里，这个问题处理得不够好，这里有两份类似项目的优秀做法”。
这对应文章里讲的“演化上下文”和“在 token 空间做持续学习”：Agent 不仅记住一个人曾经问过什么，还会对这些履历做总结和重构，把它变成未来协作时的隐形上下文。
更有意思的是，如果你允许 Junior 和 Agent 共同维护一个“日记文件”（类似作者提到的把会话提炼成日记、再反思更新 CLAUDE.md），那么知识管理就不再只是组织资产，而是开始组织人和 Agent 的联合认知过程：
这些，是传统 KM 很少被系统记录的，但对一个咨询公司的“人才复利”，可能是最关键的资产。
五、从“项目库”到“智能体栖息地”：几点判断
结合这轮 Agent 设计的共识，我会给出几个偏策略性的判断，供各位咨询行业的从业者参考：
知识库要降级为基础设施，升级的是“上下文编排层”
未来重要的不是“有多大知识库”，而是“对一个具体任务，你如何在 10 秒内编排出一个可执行上下文”。
所以要重点投入在：任务分解、检索策略、工具调用和人机协作流程上。
Junior 加速成长，关键不在“给到更多材料”，而在“暴露思考路径”。
Agent 可以把“一个合伙人会怎么走完这个 case”变成可被重放的轨迹，而不仅是最终 deck。
这要求你愿意让 Agent 进入真实项目过程，而不仅是用历史数据“离线训练”。
优秀的 KM 体系，应该天然支持多 Agent 协同
文章提到未来的一大挑战是多智能体协调：不同 Agent 在看不到彼此上下文时，很容易做出冲突决策。
咨询公司的现实也类似：行业组、地域组、职能组往往各自为战。
如果 KM 的设计一开始就以“共享工作空间 + 清晰的变更轨迹”为中心，而不是以“静态报告”为中心，未来要引入多 Agent 协同会轻松很多。
真正的护城河，不是“谁先上 Agent”，而是谁先把“上下文工程”做成组织能力；工具最终会趋同，LLM 模型也在快速商品化。
能源源不断地生产高质量上下文（任务拆解、案例沉淀、反思机制），并把这些变成标准化技能与脚手架的组织，会在 Agent 时代保持长期优势。
对于咨询公司来说，“知识管理”正在从一个 IT 项目，变成一个 Agent 设计问题；而 Agent 设计的核心，是把有限的上下文当成稀缺资源来经营。谁能先把这件事做明白，谁就更有资格在下一轮竞争里，继续把“经验”和“判断力”当成自己的主业，而不是沦为一个给通用模型“打杂”的外包供应商。
粤ICP备14082021号
免费POC，
零成本试错
