人工智能AI AgentAgent 编排AI 技能【免费下载链接】oh-my-opencode-slimLean, fine tuned Opencode multi agent suite · Mix any models · Auto delegate tasks项目地址https://gitcode.com/gh_mirrors/oh/oh-my-opencode-slim点击查看免费下载导读本文系统讲解 oh-my-opencode-slim 仓库中面向 AI 工程技能engineering skills的领域文档消费协议即 docs/agents/domain.md 定义的全部规则探索代码库前必须先读哪些文件、术语表词汇如何使用、缺失文档时如何静默降级、Triage 标签与 Issue 流程如何路由、以及输出与既有 ADR 冲突时必须如何显式标记。读完本文你将掌握一套可复用的先读域文档再动手的仓库探索工作流并理解该协议背后由 CONTEXT.md、docs/adr/ 与 codemap.md 共同支撑的领域模型是如何在源码中落地成形的。一、协议概览为什么 Agent 需要一份领域文档消费协议oh-my-opencode-slim 是一个运行在 OpenCode 之上的多 Agent 编排插件仓库内部同时存在多种角色编排器orchestrator、多个专家子代理explorer、librarian、oracle、designer、fixer、observer、动态生成的 councillor 子代理以及由 hook、skill、tool 组成的运行时子系统。当这些 Agent 以编程方式探索该仓库时如果各自使用不同的术语、忽略架构决策记录、或自行发明概念名称就会产生漂移Issue 标题、重构提案、测试命名无法对齐甚至与既有决策直接矛盾。domain.md正是为解决这个问题而存在的消费侧协议consumption-side protocol它不规定仓库的领域模型本身而规定 Agent 在探索代码库时应如何消费仓库的领域文档——读什么、用什么词、缺文件怎么办、与 ADR 冲突怎么表态。它与仓库根部的 AGENTS.md仓库操作规范、CONTEXT.md领域术语表、codemap.md架构地图共同构成一套自洽的文档体系。二、探索前的必读清单CONTEXT.md、ADR 与 codemapdomain.md规定Agent 在深入任何目录之前必须读取以下三份仓库根级文档1. CONTEXT.md —— 领域术语表与架构叙事CONTEXT.md 是项目的领域词汇表domain glossary位于仓库根目录。协议明确要求定义描述术语是什么意思而非如何实现——这是与 codemap讲实现结构之间的根本分工。其核心内容包括域关键术语AgentsAgent、Orchestrator、Subagent、Explorer、Librarian、Oracle、Designer、Fixer、Observer、Council、Councillor、Agent mode、Protected agent、Custom agent、ACP agent、Display name、Agent aliasCouncilConsensusunanimous/majority/split三档、Council preset 与default_preset的语义区分Multiplexer SessionsMultiplexer typeauto/tmux/zellij/herdr/kitty/cmux/none、Pane、Child session、Close reasonBackground JobsBackground job、Job Board、Job staterunning/completed/error/cancelled/reconciled、Job alias、Terminal stateSkillsSkill 及内置技能清单codemap、clonedeps、simplify、deepwork、reflect、worktrees、oh-my-opencode-slimloop-engineering存在于磁盘但未注册为 bundled skillHooksHook对 OpenCode 生命周期事件的响应扩展点LoopLoop、Loop phase、Execute agent、Verify agent、Success criterionInterviewInterview、Spec block、Interview dashboardCompanionCompanion桌面端活动镜像助手ConfigPlugin config、Preset、Model entry、Model inheritance、Variant、Fallback/failover、Disabled agents术语表还专门开辟了Flagged一节记录真实存在但不阻塞的术语碰撞与历史漂移例如 Presets 一词同时指插件级 per-agent override 集合与 council 的 councillor 阵容同一单词、不同 JSON 路径与类型配置键的命名风格在 snake_casedisabled_agents、main_pane_size与 camelCaseautoUpdate、backgroundJobs之间混用且无文档规则。这些标注的价值在于让 Agent 在写作时意识到碰撞的存在而不至于在 Issue 或提案中造成歧义。2. docs/adr/ —— 架构决策记录docs/adr/ 存放仓库的架构决策记录Architecture Decision Records。协议要求在进入将要工作的区域之前先阅读触及该区域的 ADR。仓库当前收录的 docs/adr/001-session-reflection-mode.md 是一个很好的样例——它完整记录了/reflect --sessions会话考古模式的决策过程实现方式决策采用 prompt-only仅扩展 reflect 技能的 SKILL.md不新增代码工具或命令 hook理由是与/reflect现有工作方式一致、LLM 已有 Read/Write/Bash 工具、符合 YAGNI命令语法决策移除从未发布的--global新增--sessions与--last N如/reflect --sessions --last 20会话发现决策LLM 读取~/.local/share/opencode/log/opencode.log并 grepsession.idses_[a-f0-9]提取会话 ID并给出了日志样例存储位置决策反思摘要统一存放于~/.config/opencode/oh-my-opencode-slim/reflections/sessions/、weekly/、monthly/ 分层并附带了备选方案对比表XDG 目录、项目本地目录、不落盘及取舍结论两阶段架构决策先逐会话反思、再聚合session → weekly → monthly 层级聚合聚合基于 20k~30k tokens 的精炼摘要而非原始会话缓存模式与 JSON 摘要 SchemaLLM 自管缓存存在即加载每条会话产出包含session、goal、success、frictions、recommendations、confidence等字段的结构化 JSON并给出 0.9-1.0 / 0.7-0.9 / 0.5-0.7 / 0.5 四档置信度评分标准。这份 ADR 展示了协议所期望的 ADR 形态包含背景、决策、理由、备选方案、落盘结构、schema 与后果使后续 Agent 可以低成本继承决策上下文。3. codemap.md —— 架构地图codemap.md 是仓库自身的架构地图被 AGENTS.md 引用。协议要求在进入某个目录做深度工作之前先读它来了解模块职责与集成点。仓库根部 codemap 的内容包括系统入口点表package.json清单与发布脚本、src/index.ts插件引导组合根聚合 agents/tools/MCPs/hooks/后台任务板/面试/缓存监控/orchestrator-wake/TUI preset 切换等并导出 v1/v2 双入口、src/cli/index.ts安装与引导 CLI、src/config/schema.tsZod 配置 schema 事实源、scripts/generate-schema.ts由 schema 生成 oh-my-opencode-slim.schema.json目录地图src 下 agents、cli、config、hooks、interview、mcp、multiplexer、skills、tools、utils、v2、companion 等各目录的职责摘要与各自的 src/codemap.md 子地图入口运行时控制流插件启动config 加载 → agent 定义 → 工具/MCP 注册 → hook 挂载、交互请求处理orchestrator prompt 路由 → 工具解析 → hook 转换、委托执行后台任务板 task-session-manager orchestrator-wake TUI 客户端 pane 生命周期、安装/发布路径关键跨模块集成点如src/hooks/task-session-manager/依赖src/utils/background-job-board.ts等一组工具模块且只经由src/hooks/cache-safe-injection.ts注入提示词src/multiplexer/仅客户端使用由src/dependency-contract.test.ts的 I1 不变量强制约束推荐阅读顺序codemap.md→src/codemap.md→ 相关子系统子地图。三、静默容错规则缺失文档时安静地继续domain.md对文档缺失场景给出了明确的纪律如果上述文件中的任何一个不存在Agent 应当静默继续proceed silently——不标记缺失、不主动建议创建。原因在于/domain-modeling技能经由外部技能/grill-with-docs与/improve-codebase-architecture触发并非本仓库内置技能会在术语或决策真正得到解析时才按需lazily创建这些文件。这条规则把文档建设与文档消费解耦Agent 探索代码库是第一优先级文档补齐是领域建模技能在被显式调用时的职责二者不应互相阻塞。这也意味着协议本身是宽容的——它不把文档齐全当作探索的前置条件。四、术语纪律用术语表的词汇说话协议对 Agent 输出的词汇选择有硬性要求当输出需要命名一个领域概念时无论出现在 Issue 标题、重构提案、假设还是测试名中必须使用 CONTEXT.md 中定义的术语不得漂移到术语表明确回避的同义词。术语表中就明确列出了被拒的同义词explore应使用explorerfrontend-ui-ux-engineer应使用designer。这背后是一条实用信号机制如果所需概念在术语表中还不存在那是一个值得注意的信号——要么是 Agent 正在发明项目不使用的新语言应重新考虑措辞要么是术语表存在真实缺口值得为/domain-modeling记录。换句话说术语表的完备度被当作领域语言一致性的晴雨表。五、Triage 与标签体系从角色到仓库标签的翻译层协议指明运维层面的 triage 角色及其仓库标签以 docs/agents/triage-labels.md 为事实源source of truth并配合 docs/maintainers.md 使用外部 PR 的 triage 策略则位于 docs/agents/issue-tracker.md。角色到标签的映射triage-labels.md将mattpocock/skills中triage技能的规范角色名映射到本仓库 Issue 跟踪器的真实 GitHub 标签字符串。其定位是角色是技能行为字符串是仓库策略的翻译层mattpocock/skills 角色本仓库标签含义bugbug有东西坏了enhancementenhancement新功能或改进needs-triage不贴标签维护者需要评估needs-infoneeds-info等待报告者补充信息ready-for-agentgood-to-code规格完整可交给 AFK Agentready-for-humangood-to-code需要人来实现wontfixwontfix不会处理三个关键注释值得展开其一needs-triage刻意没有标签——未贴标签的 Issue 隐式处于 needs-triage 状态这避免了贴标签来标记未评估的冗余其二ready-for-agent与ready-for-human都映射到good-to-code区别在于由谁实现Agent 还是人而status:in-review是独立的人工审查状态代码已存在待审查不得贴给仍需实现的 Issue其三status:in-review、release、Share Your Thoughts、community-preset四个仓库标签刻意处于 triage 分类法之外/triage不得应用它们。路由与关闭流程docs/maintainers.md 进一步给出了完整的运维流程bug 报告与功能请求进 GitHub Issues安装/排障/使用类问题去 Telegram 渠道路由新 Issue 时bug 或 feature 走/triage技能由npx skills add https://github.com/mattpocock/skills --skill triage安装标签映射已内置无需运行/setup-matt-pocock-skills支持请求则简要回复并引导去 Telegram。关闭策略上仓库当前手动关闭 Issue、不使用 stale-bot 自动化。Issue 与 PR 的操作约定docs/agents/issue-tracker.md 给出了基于ghCLI 的完整操作约定并强调写操作创建/贴标/评论/关闭必须指向上游跟踪器显式传--repo alvinunreal/oh-my-opencode-slim或设置GH_REPO否则在 fork 克隆中裸gh命令会误改自己的 fork。其 PR 策略要点是PR 被当作附带代码的功能请求进入 triage 队列但只做类别标注bug/enhancement不进入 triage 状态机、永不自动关闭护栏包括按authorAssociation过滤保留 CONTRIBUTOR/FIRST_TIME_CONTRIBUTOR/FIRST_TIMER/MANNEQUIN/NONE丢弃 OWNER/MEMBER/COLLABORATOR而不是按 PR 内容过滤且 PR 计数不得混入 Issue triage 统计。六、ADR 冲突标记宁可显式不可静默覆盖协议对 Agent 输出与既有 ADR 冲突的情形给出了明确的处理方式显式表面化surface it explicitly而非静默覆盖。domain.md提供了标准句式模板Contradicts ADR-001 (session reflection mode) — but worth reopening because…这条纪律的工程价值在于ADR 是团队决策的持久化记录静默推翻会让后续读者失去决策上下文。显式声明冲突哪怕结论仍是值得重开至少保证了决策轨迹可追溯、可被其他 Agent 或人类维护者复核。七、源码层面的领域模型佐证协议背后的实现形态domain.md提到的领域词汇并非纸上谈兵而是可以在源码中一一对位的。以术语表中两类最重要的 Agent 概念为例Councillor从预设到动态子代理council-agents.ts 中的buildCouncillorAgents第 14~50 行是Councillor一词的落地实现它遍历council.default_preset缺省default对应 preset 的每个条目把每个 councillor 构造成名为councillor-name的动态 AgentDefinition——前缀常量定义在第 5 行COUNCILLOR_AGENT_PREFIX councillor-加前缀的原因在注释中写明裸名称如alpha可能与 OpenCode 保留的 agent 类型名冲突。若配置了多模型回退链cfg.models.length 1则把_modelArray挂到 agent 上并清空单模型字段避免单模型字段覆盖回退链。第 56~60 行的getCouncillorSeatName则是前缀的逆运算用于把councillor-alpha还原为用户可见的座位名alpha。这正是 CONTEXT.md 中 Councillor is registered ascouncillor-namefrom the council preset 与 Not hidden; visible in the TUI as panes 的实现依据。Council 合成器无工具、结构化报告council.ts 中的createCouncilAgent对应术语表里的 Councilmulti-LLM agent运行若干 councillor 并综合其观点。其提示词明确声明 council agent 是多模型共识合成器、不自行派发 councillor由 orchestrator 负责派发并提供结果、且没有任何工具合成仅基于上下文中的 councillor 响应。输出强制包含Council Response、Per-Councillor Details必须使用每个 councillor 的精确座位名如alpha而非模型标签、Council SummaryConsensus Level 取unanimous|majority|split、Agreed Points、Disagreements resolution、Remaining Uncertainty、Recommended Action三部分——这与 docs/council.md 中描述的council 响应包含合成答案、逐 councillor 详情、共识评级完全一致也与 CONTEXT.md 对Consensus的定义unanimous/majority/split逐字对位。权限方面它使用createSynthesisOnlyPermission()仅合成、无文件/命令能力从源码结构看这是对read-only advisor定位的权限层落实。这种文档定义术语、源码落实行为、测试与 schema 保证一致性的结构正是domain.md协议想要 Agent 在探索时建立的心智模型术语表讲语义、ADR 讲决策、codemap 讲结构三者互相印证。八、实战工作流一次符合协议的领域探索将domain.md的规则串起来规范的探索流程是读根级文档先读 CONTEXT.md 建立术语表心智模型扫一遍 docs/adr/ 找出与任务区域相关的 ADR再读 codemap.md 定位模块职责与集成点若缺失任一文件静默继续定位目标区域依据 codemap 的目录地图进入对应子系统的 codemap.md如涉及 agents 就读 src/agents/codemap.md并按推荐阅读顺序逐层深入用术语说话输出Issue 标题、重构提案、测试名一律使用术语表词汇遇到新概念先判断是术语表缺口还是自造语言对齐运维流程涉及 Issue/PR 时遵循 docs/agents/triage-labels.md 的标签映射、docs/maintainers.md 的路由流程与 docs/agents/issue-tracker.md 的gh操作约定写操作务必指向上游仓库冲突显式化若结论与既有 ADR 相悖用标准句式显式声明冲突交由人类或后续 Agent 复核决策轨迹。结语docs/agents/domain.md虽短却是 oh-my-opencode-slim 多 Agent 协作体系的探索宪法它以最小规则集约束了术语一致性CONTEXT.md、决策继承ADR、结构导航codemap、运维路由triage-labels maintainers issue-tracker与冲突处理显式标记五个方面同时以缺失即静默的宽容条款保证了探索永不阻塞。对于希望为该仓库贡献代码、撰写 Issue 或构建技能的研究者而言这套协议是进入代码库前最值得先读的一份文档——它让你从一开始就用这个项目自己的语言思考。赞分享人工智能AI AgentAgent 编排AI 技能【免费下载链接】oh-my-opencode-slimLean, fine tuned Opencode multi agent suite · Mix any models · Auto delegate tasks项目地址https://gitcode.com/gh_mirrors/oh/oh-my-opencode-slim点击查看免费下载相关推荐Feishin 领域文档消费约定Agent 如何基于 CONTEXT 与 ADR 探索代码库Feishin 领域文档消费约定Agent 如何基于 CONTEXT 与 ADR 探索代码库 Feishin 仓库在 docs/agents/domain.m桌面应用音视频前端为什么选择CharacterPickerViewAndroid开发者必备的UI控件库为什么选择CharacterPickerViewAndroid开发者必备的UI控件库 CharacterPickerView是一款专为Android开发者打造人工智能AI AgentAgent 编排AI 技能Bindu为 AI Agent 打造的身份、通信与支付层——bindufy() 一站式接入 A2A、DID 与 x402Bindu为 AI Agent 打造的身份、通信与支付层—— bindufy 一站式接入 A2A、DID 与 x402 导读 本文基于 i18n/README上一篇Certbot革命性特性解析ACME协议客户端如何彻底改变SSL证书管理下一篇TinyKVM调试技巧使用RSP客户端进行远程调试创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
