wiki对agent workflow的价值
开展长时间、持久化的项目，基于agent的工作流会出现一些问题：
- 用户和agent的context是没有对齐的
- （未对齐的术语）工作时需要澄清一些项目特有的、容易混淆的概念
- （缺乏共识）LLM不了解你的想法，你提出一个想法，它会产生理解偏差，并做出不符合你预期的结果。
- 传统文档（例如
AGENTS.md）有很多缺点- 你希望文档实时更新，但是很可能更新的同时又破坏了无关内容
- 文档是不断积累的，在反复多次修改中会产生目的漂移
- 过大的单一文档会占用过多context，降低LLM的理解能力
借助wiki这个为人熟知的概念，LLM能够获得一个长时间有效的外部知识库。 wiki本身是相互链接的一组文档。它能够相互独立地创建、维护不同的文档，使得修改操作能够原子化、更新相对独立。 这种特性使得它十分适合巨大代码库/长期项目等，它们的文档需要不断更新、相对独立知识库。
但是wiki本身也存在不少问题，它需要巨大精力维护，需要可靠的信息来源。 这两点恰好适合LLM解决，可以定期维护wiki，并由用户提供材料来更新wiki。
Karpathy’s LLM Wiki
Karpathy’s LLM Wiki提出了一种使用LLM管理wiki的方案。 它将运营wiki的方式形式化为3个原子操作：
- Ingest：读取用户提供的源，并将它转为wiki
- Query：用户提出问题，LLM根据wiki回答问题
- Lint：（定期）让LLM检查wiki的健康程度，检查过时内容、内部矛盾等
上面的方法更像是维护wiki本身的原语，我则更希望wiki服务于项目。
面向user taste的wiki
不难发现，单纯将外部用户资源整合起来作为wiki的内容意义不大，用户至少应该起到指明方向、筛选信息源的作用。 进一步考虑，为了解决上面“和用户context对齐”的问题，其实我们更需要以用户作为信息来源。用户的taste可能是独特的，不存在于互联网或LLM的参数化知识。数据来源上，用户和agent的对话天然体现了他的taste，可以通过在线记录（用户显式告诉agent记录到wiki）、事后总结（定期分析多个traces）的方式提炼wiki的内容。这样做，wiki中会积累用户相关的taste、insights等，对于长期的任务来说十分有效，它可以让agent像你一样思考（这对research等高创新任务尤其有价值）。
个人观点：最有效率、能体现优势的使用agent的方式是将你独有的、个性化的东西提供给agent，从而获得个性化的agent。
上述“将用户taste和外部知识记录到wiki”的定位理论上更有效，但是在实现上存在问题。最主要的问题在于，LLM难以从trace中提炼有效的知识，可能是片面的、低价值的，从而构建出不够准确的wiki。 作为缓解的措施，或许可以让用户承担更多的责任，例如用户主动和LLM讨论并复盘，合作提炼wiki的内容。