LLM Wiki

Appearance

Built 26/04/17 09:08commit f8ff6f9

Agent 优先仓库 ​

中文 | English

摘要 ​

Agent 优先仓库意味着：模型可以直接从版本化的本地产物中理解产品、架构、质量标准和运行状态，而不依赖隐藏在人类脑海中的上下文。

核心原则 ​

  • 人负责意图与优先级，agent 执行大部分实现和维护工作。
  • 仓库内产物是 system of record，因为仓库之外的东西对 agent 来说几乎等于不可见。
  • AGENTS.md 应该是通向深入文档的紧凑地图，而不是一个单体指令墙。
  • 渐进式披露优于百科全书式指引：先提供稳定入口，再告诉 agent 往哪里钻深。

可读性杠杆 ​

  • 让 UI 可读：浏览器自动化、截图、DOM 状态、可重复启动流程。
  • 让前端品味可读：把 DESIGN.md 这类 repo 内设计契约写清楚，让 agent 能依据持久规则而不是只靠聊天里的零散指令做视觉判断。
  • 让运行时可读：日志、指标、trace 和其他可查询的观测面。
  • 让架构可读：固定层次边界、域图、依赖方向的机械检查，以及可再生成的架构图工件，让系统结构能继续从 repo 内文本被读取和重建。
  • 让循环状态可读：把 specs、PRD、fix plan、progress log 之类的小型耐久文件留在仓库里，让每次新上下文运行都能快速重载。
  • 让交付流程可读：计划、review 评论、质量等级和修复模式都保存在仓库内。

控制系统 ​

  • 把重要约束编码进 lint、结构测试和能指导恢复的错误消息。
  • 把人类品味和不变量一次性写成文档或工具，然后持续执行，而不是反复口头解释。
  • 把耐久操作默认值放进 config.toml，把仓库规则放进 AGENTS.md；prompt 只承载任务局部差异，而不是整本操作手册。
  • 可复用的命令束很重要，因为它们把原本模糊的方法论变成可检查的仓库控制面：ideation、planning、review 与知识沉淀都可以作为具名命令分发，而不再依赖口口相传。
  • 可复用的 agent 操作模型本身也可以被打包成 skills、plugin manifest 与 bootstrap 脚本等仓库资产，让控制面能够跨项目迁移。
  • 成熟的 agent 仓库往往会同时把同一套操作模型暴露成多个 harness 原生执行面，例如 Claude plugin、Codex 配置与 roles、Cursor/Kiro/OpenCode 子树，以及让这些面保持对齐的 installer 脚本。
  • 面向团队的 agent 仓库还需要一套分发故事：全局安装、项目 bootstrap、环境检查、升级路径，以及 runtime 注册流程，正在逐渐成为仓库契约的一部分。
  • 跨 runtime 的 bridge plugin 也是一种新兴 repo 表面：它把一个 agent 系统打包成另一个系统里的原生命令，使 review 车道、委派工作与验证 gate 变成可安装的仓库级资产，而不是临时拼起来的 shell 编排。
  • 有些仓库还会把单一 agent 环境表述成“虚拟工程办公室”，用具名角色把产品、设计、QA、安全与发布这些审查视角做成仓库内原生车道，而不是聊天中的临时提醒。
  • 紧凑的方法论包可以同时以 plugin 元数据、项目说明文件和可复用 skill 的形式传播，把一次操作者经验变成可移植的仓库资产。
  • 有些 agent-first 系统还会进一步把 issue board、daemon 挂载 runtime，以及可分派的 agent 身份一起纳入操作面，而不只停留在 repo 内控制层。
  • Prompt 清单型仓库也是一种正在浮现的可读性层：它把原本隐藏的 builtin prompts、tool 描述、安全监控器与 utility routines 变成可检查、可 diff 的版本化资产。
  • 把周期性清理当作垃圾回收，使坏模式在扩散前就被纠正。

取舍 ​

  • 更严格的边界和显式脚手架能提高 agent 吞吐，但也要求持续维护仓库中的指导面。
  • 高吞吐会改变合并哲学：短 PR 和廉价跟进修复，往往比漫长的人类阻塞 review 队列更合适。
  • 高自治也带来长期问题：熵、架构漂移，以及人类判断应当施加在什么地方才最有杠杆。

来源 ​

相关页面 ​