如果你高强度使用 Agent Coding,不妨了解一下我个人沉淀的项目管理方法(Agent 优先)

本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:

  • 我的帖子已经打上 开源推广 标签: 是
  • 我的开源项目完整开源,无未开源部分: 是
  • 我的开源项目已链接认可 LINUX DO 社区: 是
  • 我帖子内的项目介绍,AI生成、润色内容部分已截图发出: 是
  • 以上选择我承诺是永久有效的,接受社区和佬友监督: 是

以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出


补充

建议佬们先让你们的 Agent 充分理解,结合自己的情况决定蒸馏到自己的方法论或 skill,还是直接安装使用

欢迎大家一起讨论关于人与 Agent 协作的探索和经验,这个 skill 最重要的目的是分享自己的方法论

我是一个重度的 Coding Agent 用户,我的 Agent 基本上 24 小时不间断地在跑。学习调研、工作项目、开源项目、折腾安卓自动化、折腾电视、分析投资、管理生活事项等等,都在尝试让 Agent 参与。最近也一直在 Codex、Claude Code、DeepSeek Harness 之间折腾,希望找到更舒服、更高效的使用姿势

之前为了随时随地使用 Agent,还做了一个安卓 SSH / mosh 客户端 moke,在站里分享过:

用得越多,另一个问题就越来越明显:项目和工作目录很多,会话也很多,我自己的想法、需求、个人偏好,上次工作推进到哪里、为什么选了这个方案、调研中间发现了什么,经常散在不同的对话里。换个会话或者换个 Agent,又得重新解释一遍;有些当时很有价值的东西,过段时间就找不到了

目前接触到的记忆方案还没有让我特别放心,记什么、怎么更新、什么时候能用上,都还有不少问题,这里先不展开。各家 Harness 自带的记忆也有各自的存储和加载方式,换一个工具,之前积累的东西未必能直接接着用

OpenViking 是一个不错的方向,把知识、记忆和技能统一组织成虚拟文件系统,通过目录、分层摘要和检索来按需获取上下文,也能从会话里提取长期记忆,适合需要持续积累、跨会话复用上下文的场景。Github:volcengine/OpenViking

我没有实际用,对我目前的需求来说,额外的服务、模型配置和 Agent 接入维护稍微有些重。我更希望直接在项目目录里看到和修改全部内容,用普通文件和 Git 就能管理。我自己更顺手的方案,就是这次分享的 knowledge-project

最初的萌芽是一月份折腾 OpenClaw,后来到 Hermes,再到越来越多项目开发时维护的 docs 目录。我一直在积攒和迭代:项目知识怎么组织,代码和数据怎么放,工作进度怎么接续,经验和个人偏好怎么沉淀。折腾了大半年,如今我个人的项目都在用这套方法来管理,也就把它整理成了一个 skill

skill 只提供方法论,所有项目上下文都保存在项目文件里

项目的目标、约定和协作偏好写在 AGENTS.md,工作进展、关键决策和下一步记到 log.md;调研结果、方案和踩坑经验按内容组织,需要的时候再读。代码和数据保留各自的格式,知识文档用 Markdown,参考了 OKF 的文件组织和 YAML 元数据约定

也约定了怎么从试错过程里留下有用的东西,什么时候该调整项目结构,规则越来越多时怎么精简,希望每次工作结束后,除了完成眼前的任务,还能留下有用的积累

对我来说最实用的地方是,换 Agent、换会话之后,可以让它从项目文件里恢复目标、约定和进度,接着往下干。项目建立起来以后,即使没有安装这个 skill,也能按项目里留下的规则继续维护。我自己随时能看、能改,也不用额外维护一个记忆服务

下面是 description,能比较好的描述清楚应用场景和效果:

让知识工作项目对 Agent 自描述、跨 session 可接续,并治理项目里的规则与工作纪律。

两类场景使用:(一)项目组织——新建或初始化项目、整理或健康检查项目结构、设计目录与导航、写 frontmatter/index/log/决策记录、把探索期的临时文件沉淀下来、恢复一个还没有规则文件的项目的上下文;(二)工作方法论——同类问题反复出现要固化成规则、规则太多或互相冲突要精简、新增或删除一条项目规则、给项目立检查脚本或门禁并判断它是否有效、沉淀经验教训、回顾或改进方法论本身。

触发词:新建项目、初始化文档结构、帮我整理这个项目、项目怎么组织、健康检查、又踩坑了、固化成规则、规则太多、精简规则、门禁、检查脚本、沉淀、蒸馏、经验教训、决策记录、回顾方法论、setup project、project health check。

新开一个学习调研项目,可以直接说“用 knowledge-project 初始化一下这个项目”;一个项目折腾了很多轮,文档、脚本、临时数据越堆越多,就说“帮我整理这个项目,把有用的结果和经验沉淀下来”;同一个坑反复踩,或者 AGENTS.md 越写越长,就让它检查和整理规则。这样下次再来,可以直接找到之前的结论、方案取舍和下一步要做的事,不用重新翻一遍聊天记录

项目地址:

安装:

npx skills add briqt/knowledge-project -g -y

装好后,直接让 Agent 用 knowledge-project 整理一下当前项目,或者初始化一个新的知识项目就可以。大家如果也经常在多个项目、多个 Agent 之间切换,可以试试看,有问题或者更好的想法欢迎交流,我持续使用、持续迭代

38 个赞

我用obsidian+skill,目前比较够用。

我是用思源笔记+自己根据官方接口文档和 MCP 封装的 cli,用于存文档和笔记,长期知识,比较好用;
组织项目迭代和会话,这种偏向碎片化、规则化的经验知识和项目文件,有些不合适

已经star,这么体系化的东西,值得让AI学习一下

这个思路很实用,AGENTS.md + log.md 的组合确实比藏在工具内部的记忆更透明可控。我自己的补充是:log.md 里除了记决策和进度,还会让 Agent 在每次会话结束时写一段“本次学到的教训”,下次遇到类似问题先读这部分,踩坑重复率低很多。另外目录层面建议加一个 decisions/ 或 adr/ 放架构决策记录,时间久了回看比翻 log 更快。

1 个赞

认同佬的补充,沉淀经验和保留决策是最优先需要规范和整理的内容

我这个 skill 里也有这些约定,lessons.md 记教训,wins.md 记有效做法
决策记录默认跟相关文档放在一起,需要时再单独拆文件或目录,同一个坑反复踩,就考虑加规则或检查
相关内容会通过项目入口和路由接起来,让 Agent 知道做这件事之前应该读哪里

我的整体思路是提供分层级和自迭代抽象指导,以及对应不同层级的具体方向指导,不要求每一个项目都必须怎样;尽量少规定一些统一的形式,留有各自 Agent 和用户个人偏好和自由空间

佬对于项目会话的整理有心得可以分享一下吗,干活太多之后,会话自动总结的标题内容不是特别直观,之前也让agent通过规则进行过标题整理,但还是让会话越堆越多,想归档的时候又因为会话太多了越来越懒:face_exhaling:

泼盆冷水吧,看得出来你很高强度用agent了,这整篇稿子AI味道很重,这个knowledge-project真的有用吗?和你平时随时让AI帮你总结的优势在哪里?现在最大的问题早就不是说是你不知道AI在干嘛了,而是AI告诉你它在干什么之后,你看不懂他说的东西,你也不知道他做的东西是不是真的是不是符合要求的或者说你不知道它做的东西坑到底在哪里,你把所有东西都记下来了,你真的有时间看吗?所有的工作记录是干活的员工需要的,你是吗?你是Agent的老板,你提出需求,你最大的关注点是这个到底能不能完成,或者你问的问题到底能不能解决,怎么去进行一个合理的review才是关键

11 个赞

这个可以啊佬,最近我都想学习一下知识库的分配

没看懂是怎么实现的, 点了一个star

现在的Ai自主性太强了,需求和效率都上去了,一天写的代码破万都是常有的事情,总结成文字的形式过几天都会忘了,就算是记忆规则,你也不会看他中途的代码实现,都是看result结果的。完成让子agent去把这个改动和需求绘制成可视化场景或者游戏会好很多,然后提炼这个作为每天的可视化观察会比文档有趣的多,人对静态文字的记忆感官始终不如视觉带来的好

1 个赞

知识库这种东西到底应该怎么样才有用?随时调用吗?如果是概念类的静态知识,或者什么什么的标准流程,点开手机上的聊天LLM就能随时问到的还有整理进自己知识库的必要吗?知识库里有价值的东西到底有多少?这么一股脑的把所有东西全都丢进自己的知识库,到底是知识库还是归档库还是垃圾库。你真正需要review的是,这个项目AI怎么给我做的,怎么给我执行的;执行层面很多时候你都看不懂,你不可能再把其中的每一段代码抠出来挨个做个注释看一下;这就需要抽象一层,你得让他说明白他为什么选这些方法,或者说在执行层上已经留了证据了,往上抽象一层,在路径层上为什么定下当前的方法论;再往上抽象一层,来到哲学层面,你问明白AI到底秉持着怎样的行动哲学来给你解决的你提出的问题。从上到下,哲学层统一,目标与边界一致,ok接下来看路径层,路径层和哲学层保有一样的一致性,ok,这个时候执行层做的东西你基本才可以判断AI做的是对的,没有说是单纯为了你的要求去硬凑或者什么情况,这个时候你可以对具体的技术细节是不了解的,你干个县长你要发展一片奶牛养殖园,工人一天挤几次奶你需要了解吗?不需要啊

5 个赞

你的意思是一天agent写了一万行代码,然后你认为看不完,所以你打算把这一万行代码做成“可视化观察”,然后你投入了一大堆时间进去,最后你觉得通透了,那么下次再次碰到AI生成的一万行代码,你能直接就替他review吗?还是说你能做到手写一万行代码了?你的注意力就这么多,人的上下文是很短的,你看懂了你做得到吗?看个几百行顶天了,你的人脑又没有那么高的算力

2 个赞

1.知识库不是人来校对过的没什么用。
2.这个项目不应该叫知识管理,看上去是 agent 上下文存续 和 onboard。
3.另外应该说明下各文档的生命周期。
4.最好放一个实际的知识库结构。

MCP不能直接用吗,佬为啥还封装了cli

对,我这边自己做的知识库就是给AI用的,方便项目开发,但是人怎么管理这个还没啥好的方案,佬有啥推荐的吗

相当厉害了,学以致用。一直想找个好用的开源ios上ssh应用,可惜一直没找到合适的。

每天与我输入输出最多的是AI,我已经是 AI 的形状了…

knowledge-project是否有用、相对于随时总结的优势、我是否知道过程和关键、是否理解它的产出、如何 review:

如正文所述,这是我所有使用 Agent 过程中的一次次随口描述和协作过程中的管理方法论的总结,与我而言相比于不用,真的有用;

后半段的问题,这个方法论无法解决,我没找到完美的答案,也是我在不断探索的方向;最近的两个中高等复杂度的项目,使用这套方案+许愿式开发,得到的是半失控的结果,导致我失去了对项目的掌控。

这方面我的探索是:

  1. 我在调整摸索针对不同的模型、不同类型的任务,由我来调整下发任务的粒度
  2. 每个回话都要经常强调“讲人话”,合理使用 askme,让我参与决策
  3. 仍然没有找到合理的 review 方式

受教了

额,为什么会觉得投入了很多时间呢?一句话提示很难吗?你的业务场景你让他整理输出不会吗?你不知道自己要做什么吗?可视化场景看的是逻辑,思路和实现方法,看文档就是不如看图场景很难理解吗?没搞懂你说的话,另外一天代码总共1万行,实际业务包含前后端测试,你看的是场景很难理解吗?你会看测试?你会看前端?我当然不会,所以这个方法是适合我的

MCP 相对于 skills 和 cli 多一步注册, CLI 环境兼容性更好,我不太喜欢 MCP 的使用方式,能力上是官方 MCP 更强更完善的