如何管理用于 AI 代理的 Markdown 上下文文件?
摘要
这是一篇关于管理频繁更新的用于 AI 代理的 Markdown 上下文文件的专业询问,讨论了与 GitHub、Google Docs 和 Guru 等协作与版本控制工具相关的挑战。
我们在工作中构建越来越多的代理,这意味着我们积累了更多作为代理上下文的 Markdown 文件。这些包括短期和长期策略、市场动态等,并且会由多人定期更新。我们正在寻找一种既能轻松协作和版本控制,又能保持文件为 Markdown 格式的解决方案。我们考虑过:Confluence:没人愿意用它。Google Docs:编辑容易,但最终会得到一个 Google Doc 和导出的 Markdown 文件,感觉很乱。而且你无法直接编辑 Markdown 文件,所以必须先作为 Google Doc 打开,然后将任何更改重新导出为 Markdown 文件。GitHub:从技术上讲可能是理想的,但我们收入团队中只有少数人有 GitHub 访问权限,所以不实用。Guru:我们已经有它了(尽管我们六个月前打算放弃它,哈哈),并且我们为它设置了一个 MCP 服务器。我们目前倾向于这个方向。还有其他人遇到过这个问题吗?你们使用什么来管理频繁变化的作为 AI 代理上下文的 Markdown 文件?
相似文章
@tricalt: https://x.com/tricalt/status/2057173322924806651
一位创始人讨论了在生产环境中使用Markdown文件作为AI代理记忆的扩展挑战,突出了关于权限、多代理交互和时间查询的常见陷阱,并指出团队常常在不经意间修补这些问题的过程中,实际上是在重新构建一个更复杂的系统。
@bibryam: https://x.com/bibryam/status/2084204574559056207
对新兴的基于 Markdown 的文件格式(AGENTS.md、SKILL.md、规格/计划/任务文件、记忆文件)的探索,这些格式构成一个“元代码层”,使编码代理能够直接从代码仓库中发现并应用项目知识,从而改变了意图转化为实现的方式。
agents.md文件对编码代理有帮助吗?
这篇论文评估了诸如AGENTS.md或CLAUDE.md等仓库级上下文文件是否能提升编码代理的性能,发现由LLM生成的上下文文件几乎无益甚至可能降低效率,而开发者编写的文件效果稍好,但优势仍不明确。
当编码任务变得混乱时,你在AGENTS.md里写些什么?
讨论了使用OpenClaw的开发者如何通过一个交接文档(AGENTS.md)来跟踪目标、文件、失败和决策,从而在混乱的编码会话中保持AI编码代理的上下文。
有没有其他人每次运行 agent 前都手动从 Jira/Docs/GitHub 重新收集上下文?
关于在运行 AI 代理前从 Jira、Docs 和 GitHub 手动收集上下文所需工作量的讨论。