AI AgentAgent 工作流开发工具【免费下载链接】agent-osAgent OS is a system for injecting your codebase standards and writing better specs for spec-driven development.项目地址https://gitcode.com/gh_mirrors/agen/agent-os点击查看免费下载Agent OS 的核心能力之一Discover Standards负责把散落在代码库各处的隐性知识tribal knowledge——那些新开发者不看代码就永远不知道的约定——提炼成简洁、可被 AI 直接检索与注入的工程标准文档。本文以 commands/agent-os/discover-standards.md 为骨架结合 index-standards.md、inject-standards.md 以及 scripts 目录下的安装、同步脚本完整讲解从代码分析、交互确认、标准起草到索引更新、跨项目复用的六步工作流。读完本文你将掌握如何在项目中运行/discover-standards产出一套AI 友好、token 高效的团队规范并与/inject-standards形成自动化的规范注入闭环。一、Discover Standards 在 Agent OS 中的定位Agent OS仓库 README.md是一套让 AI 编程助手按照你的方式写代码的轻量级框架可配合 Claude Code、Cursor 等工具使用。它的核心能力矩阵是Discover Standards从代码库中提取模式与约定沉淀为文档化标准Deploy StandardsInject Standards根据你正在做的事情智能注入相关标准Shape Spec创建更好的计划导向更好的构建Index Standards保持标准有序、可发现。Discover Standards 正是整个体系的源头它把代码库中实际存在、反复出现、但从未被写下来的约定变成显式的 Markdown 标准文件。据 CHANGELOG.md 记载/discover-standards是 Agent OS v32026-01-20 发布新增的核心工具它让 Agent 能够从你的代码库中提出surface、建议suggest并创建create标准。v3 的定位是聚焦建立标准与注入标准而把 spec 编写、任务拆分等能力让位给现代 AI 工具自带的 Plan Mode因此 Discover Standards 在 v3 中的地位尤为突出。一句话概括它的价值代码里已有的约定值得被记录而记录下来的约定值得被 AI 严格执行。二、运行前必读的三条铁律原文档 discover-standards.md 在正文开头给出了三条硬性准则它们决定了整个流程的交互方式与产出质量始终使用 AskUserQuestion 工具任何需要向用户提问的场景都必须通过 AskUserQuestion 工具完成而不是在对话里直接抛出开放式问题。这保证了交互是有结构、可选择的AskUserQuestion 是 Claude Code 等 AI 编程助手内置的结构化提问能力能够让用户在选项卡片上直接确认或修改见 CHANGELOG.md 中 Product planning phase streamlined with AskUserQuestion tool integration 的说明。写出简洁的标准用最少的词。标准会被注入 AI 的上下文窗口必须能被 AI Agent 快速扫读同时不能撑爆上下文窗口。每个词都是 token每个 token 都是成本。提供建议而非空问给用户呈现可确认、可选择、可纠正的选项不要让他们做不必要的思考。Agent 的工作是把决策成本降到最低而不是把问题抛回给用户。这三条准则贯穿后面全部六个步骤尤其是先给结论/建议再让用户确认或修正的交互模式。三、六步工作流从分析代码库到生成标准文件Discover Standards 的完整流程包含六个步骤。下面按原文档顺序逐一展开并补充仓库源码层面的机制说明。Step 1确定焦点领域第一步是确定我们要从哪个领域挖掘标准。如果用户在运行命令时已经指定了领域直接跳到 Step 2。如果没有指定则分析代码库结构文件夹、文件类型、代码模式识别出 35 个主要领域。原文档给出的分类示例前端领域UI 组件、样式/CSS、状态管理、表单、路由后端领域API 路由、数据库/模型、认证、后台任务横切关注点错误处理、校验、测试、命名约定、文件结构用 AskUserQuestion 向用户呈现这些领域例如Ive identified these areas in your codebase: 1. **API Routes** (src/api/) — Request handling, response formats 2. **Database** (src/models/, src/db/) — Models, queries, migrations 3. **React Components** (src/components/) — UI patterns, props, state 4. **Authentication** (src/auth/) — Login, sessions, permissions Which area should we focus on for discovering standards? (Pick one, or suggest a different area)在继续之前必须等待用户响应。这里的关键点是领域选择权在用户Agent 只负责扫描并提议。这一设计避免了 Agent 擅自决定关注点而偏离团队实际诉求。Step 2分析并呈现发现领域确定后进入代码分析阶段读取该领域的关键文件510 个代表性文件寻找符合以下特征的模式非常规Unusual or unconventional——不是框架/库的标准用法而是项目自己的特殊处理有主见Opinionated——本可以有多种做法、但项目明确选择了某一种隐性知识Tribal——新开发者不被告知就绝对不会知道的东西一致Consistent——在多个文件中反复出现的相同模式。同时满足有主见 一致的模式通常就是最值得沉淀为标准的东西它们既是团队刻意选择又被大面积使用一旦写错代价很高。用 AskUserQuestion 呈现发现让用户勾选要沉淀的候选标准I analyzed [area] and found these potential standards worth documenting: 1. **API Response Envelope** — All responses use { success, data, error } structure 2. **Error Codes** — Custom error codes like AUTH_001, DB_002 with specific meanings 3. **Pagination Pattern** — Cursor-based pagination with consistent param names Which would you like to document? Options: - Yes, all of them - Just 1 and 3 - Add: [your suggestion] - Skip this area等待用户选择后再继续。注意选项里永远留了三条退路全选、部分选、补充建议、跳过该领域——这正是Offer suggestions铁律的具体落地。Step 3先问为什么再逐条起草每项标准这是整个流程中最容易做错、也最影响质量的一步。原文档用粗体强调对于每一项被选中的标准必须完成完整的循环后才能进入下一项针对该模式背后的为什么提出 12 个澄清问题用 AskUserQuestion等待用户回答将用户回答融入标准草稿在创建文件前与用户确认获批准后创建文件。示例提问根据具体标准调整这个模式解决了什么问题为什么不用默认/常规做法有没有不应该使用这个模式的例外情况开发者或 Agent 在这上面最容易犯的错误是什么严禁把所有问题一次性全部抛出。一次只处理一项标准走完完整的提问 → 等待 → 起草 → 确认 → 建文件循环再开始下一项。这一步的价值在于标准文档记录的不只是怎么做更是为什么这么做。理解了动机AI Agent 在面对新场景时才能判断这条标准该不该套用而不是机械照搬。Step 4创建标准文件每一项标准在完成 Step 3 的问答后按以下流程落盘确定归属文件夹不存在则创建原文档给出的可选目录包括api/、database/、javascript/、css/、backend/、testing/、global/检查是否已有相关标准文件——如果有追加到已有文件而非新建避免标准碎片化起草内容并用 AskUserQuestion 确认原文档给出了标准的草稿模板Heres the draft for api/response-format.md: --- # API Response Format All API responses use this envelope: json { success: true, data: { ... } } { success: false, error: { code: ..., message: ... } }Never return raw data without the envelopeError responses must include both code and messageSuccess responses omit the error field entirelyCreate this file? (yes / edit: [your changes] / skip)4. 创建或更新文件路径为 agent-os/standards/[folder]/ 5. **然后对下一项选中的标准重复 Step 34**。 注意草稿模板本身就是一个标准标准的范本标题一句话说清主题代码块展示事实三条 bullet 分别说明边界不做什么、必选项做什么、可选项什么情况下省略什么。后面第五节会专门拆解这种写法。 ### Step 5更新索引 所有标准创建完毕后更新索引 agent-os/standards/index.yml 1. 扫描 agent-os/standards/ 下所有 .md 文件 2. 对每个没有索引条目的新文件用 AskUserQuestion 提议描述文案New standard needs an index entry: File: api/response-format.mdSuggested description: API response envelope structure and error formatAccept this description? (yes / or type a better one)3. 更新 agent-os/standards/index.yml yaml api: response-format: description: API response envelope structure and error format排序规则先按文件夹名、再按文件名一律字母序。索引文件是整个体系的关键枢纽。正如 index-standards.md 开头所解释的索引让/inject-standards无需读取全部标准文件即可推荐相关标准——它把每个标准映射为一句简短描述供快速匹配使用。换句话说索引是标准目录的目录。关于索引还有两个从 index-standards.md 补充的关键细节root是保留字指直接位于agent-os/standards/根目录下的.md文件不在子文件夹中不要创建名为 root 的实际文件夹索引条目的描述必须保持一句话——它是用于匹配的不是文档。而 project-install.sh 中的create_index()函数第 278382 行展示了该索引在实际安装时的生成逻辑脚本扫描根目录与子文件夹的.md文件优先复用旧索引中已有的description对没有描述的条目写入占位符Needs description - run /index-standards——这正是 /discover-standards 和 /index-standards 需要介入补全描述的地方。Step 6提供继续选项最后一步用 AskUserQuestion 询问用户是否继续Standards created for [area]: - api/response-format.md - api/error-codes.md Would you like to discover standards in another area, or are we done?这一步把流程设计成一个可循环的开放闭环一个领域完成后用户可以立即转向下一个领域回到 Step 1也可以就此结束。四、输出位置与目录约定所有产出的标准统一落在两个位置所有标准 agent-os/standards/[folder]/[standard].md 索引文件 agent-os/standards/index.yml这套目录约定与仓库的 profile 机制相互呼应。仓库中 profiles/default/global/tech-stack.md 展示了标准按领域目录组织的既有形态global/目录存放跨领域通用标准如 tech-stack。当通过 project-install.sh 把默认 profile 安装进项目时profile 内standards/下的所有.md文件排除.backups/目录见 common-functions.sh 的copy_standards()函数会被原样复制到项目的agent-os/standards/中/discover-standards再在此基础上增量追加新发现的标准。这种profile 提供基线标准 discover 发现项目特有标准的组合保证了每个项目的agent-os/standards/既是自包含的可提交进仓库供团队共享又能持续生长出项目自己的约定。五、写出每个字都值钱的简洁标准原文档在 Writing Concise Standards 一节 给出了为什么必须简洁的根本原因Standards will be injected into AI context windows. Every word costs tokens.标准会被注入 AI 上下文窗口每个词都消耗 token。结合 inject-standards.md 可以看到标准在实际使用中会被整篇读入对话上下文Conversation 场景、嵌入 Claude Skill 或计划文档——因此冗长的标准会直接推高每次任务的 token 成本并稀释 AI 对关键信息的注意力。为此写标准必须遵循五条规则规则先行Lead with the rule——先说该怎么做再说为什么如需用代码示例Use code examples——展示胜于讲述跳过显而易见的Skip the obvious——不要记录代码本身已经说清楚的东西一个概念一条标准One standard per concept——不要把不相关的模式揉在一起用列表代替段落Bullet points over paragraphs——可扫读性优先于可读性。原文档给出了正反两个对照非常直观。好标准长这样# Error Responses Use error codes: AUTH_001, DB_001, VAL_001 json { success: false, error: { code: AUTH_001, message: ... } }Always include both code and messageLog full error server-side, return safe message to client**坏标准**长这样原文以[continues for 3 more paragraphs]示意其冗长 markdown # Error Handling Guidelines When an error occurs in our application, we have established a consistent pattern for how errors should be formatted and returned to the client. This helps maintain consistency across our API and makes it easier for frontend developers to handle errors appropriately... [continues for 3 more paragraphs]对比可见好标准 4 行文字 1 段 JSON 就把用什么错误码、响应长什么样、必须包含什么、哪边记日志哪边回消息全部讲完坏标准写了三段话还没给出任何可执行的信息。前者是 AI 能一眼执行的标准后者是 AI 读完还要自己提炼的散文。六、完整示例一条标准从发现到落盘原文档用一整节演示了单条标准走完整套工作流的全过程这里完整复现并加注说明1. 呈现发现Step 2I found these patterns in your API code: 1. **Response Envelope** — All responses use { success, data, error } 2. **Error Codes** — Custom codes like AUTH_001 Which would you like to document?用户回复Both2. 为第一条标准问为什么Step 3For the Response Envelope pattern: - What problem does this solve? Why not return raw data? - Are there any endpoints that dont use this pattern?用户回复We use it so the frontend always knows where to find the data. All endpoints use it, no exceptions.3. 起草第一条标准Step 3 续Heres the draft for api/response-envelope.md: --- # Response Envelope All API responses use this structure: json { success: true, data: { ... } } { success: false, error: { ... } }Frontend always checkssuccessfirst, then readsdataorerrorNo exceptions — every endpoint uses this formatCreate this file?用户回复Yes **4. 创建文件然后处理下一条标准**[Create the file]**5. 为第二条标准问为什么回到 Step 3**For the Error Codes pattern:Whats the naming convention for codes?Where should new error codes be documented?用户回复Format is AREA_NUMBER like AUTH_001. We keep a list in the wiki. **6. 起草第二条标准、确认、创建文件……**[Continue until all selected standards are done]原文档最后强调的关键点**每条标准都要完整走完提问 → 起草 → 确认 → 创建循环再开始下一条**。注意示例中两条标准的问题各不相同——第一条追问为什么不用默认做法、有没有例外第二条追问命名规范、在哪里登记——提问必须贴合该模式的具体决策点而不是套用模板。 ## 七、安装与标准目录的落地脚本视角 要让 /discover-standards 在你的项目里跑起来前提是项目已完成 Agent OS 安装。结合仓库脚本可以看清标准系统的完整落地链路 **1. 安装[project-install.sh](https://link.gitcode.com/i/66312ba1434a9b3245cc11f77ef331c7)** - 在项目根目录运行安装脚本常用参数--profile name 指定使用哪个 profile默认取 [config.yml](https://link.gitcode.com/i/f3040a8241ebc789e76e9d33f022c16a) 中的 default_profile当前值为 default、--commands-only 只更新命令不动已有标准、--verbose 输出详细日志 - 脚本会创建 agent-os/standards/ 目录结构把 profile 的标准复制进来并自动生成 index.yml - 命令文档被安装到项目的 .claude/commands/agent-os/ 下/discover-standards 即由此提供对应仓库 [commands/agent-os/](https://link.gitcode.com/i/651315313866d4961c1725b566552cc0) 目录 - 安装完成后脚本提示的两个Next steps正是先跑 /discover-standards 提取代码库模式再跑 /inject-standards 将标准注入上下文。 **2. 配置[config.yml](https://link.gitcode.com/i/f3040a8241ebc789e76e9d33f022c16a)** yaml version: 3.0 default_profile: default # Optional: define inheritance relationships for profiles # profiles: # profile-a: # inherits_from: default # profile-b: # inherits_from: profile-adefault_profile决定安装时默认使用的标准基线profiles下的inherits_from支持 profile 继承链common-functions.sh 中的get_profile_inheritance_chain()会解析该链并检测循环依赖。3. 回灌sync-to-profile.sh/discover-standards发现的标准沉淀在项目agent-os/standards/后可以通过同步脚本回灌到 base profile供其他项目复用./scripts/sync-to-profile.sh # 交互式选择 profile 与文件 ./scripts/sync-to-profile.sh --profile rails # 直接同步到指定 profile ./scripts/sync-to-profile.sh --all --overwrite # 全量同步并覆盖自动备份 ./scripts/sync-to-profile.sh --new-profile nextjs --all # 同步到新 profile脚本会做冲突检测目标 profile 已存在同名文件时可选择带备份覆盖 / 跳过 / 取消备份存放在 profile 的standards/.backups/时间戳/下common-functions.sh 的copy_standards()在复制时同样排除了.backups/。这套安装 → 发现 → 索引 → 注入 → 回灌的闭环让标准既能在单个项目内被 AI 严格执行又能跨项目沉淀为团队资产。八、工作流全景discover → index → inject 的闭环最后把 Discover Standards 放到整个 Agent OS 体系中看它的上下游上游输入代码库本身 用户的领域选择。Discover Standards 从中提取模式中游产物agent-os/standards/[folder]/[standard].md标准文件 agent-os/standards/index.yml索引下游消费inject-standards.md 读取index.yml根据当前任务上下文对话、创建 Skill、Plan Mode 规划匹配 25 条相关标准并注入shape-spec.md 在规划阶段也会调用/inject-standards把相关标准带入 spec。需要特别指出的是/discover-standards会在最后一步自动执行索引更新。正如 index-standards.md 明确说明的/discover-standardsruns this automatically as its final step, so you usually dont need to call it separately after discovering standards. 也就是说正常跑完 /discover-standardsStep 5 的索引更新已经内嵌完成独立的/index-standards命令主要用于以下场景手动创建/删除标准文件之后、/inject-standards的推荐出现错位时、或索引长期未维护需要重建时。由此可以归纳出与/discover-standards配套的三个最佳实践在任务开始时尽早发现标准先沉淀标准再让/inject-standards在每次任务中自动带上它们避免每次开发都重复口述约定保持标准单条聚焦、每条极简标准是被注入到上下文里消费的简洁直接决定 AI 的执行准确率与 token 成本让发现成为习惯每当代码库出现新的稳定模式就运行一次/discover-standards或手动补一条标准再跑/index-standards让agent-os/standards/始终与代码库的真实约定保持同步。最终Discover Standards 达成的效果是团队的工程约定不再依赖老员工口口相传而是以可检索、可注入、可跨项目复用的标准文件形式成为 AI 与新人开发者都能直接执行的第一手资料。赞分享AI AgentAgent 工作流开发工具【免费下载链接】agent-osAgent OS is a system for injecting your codebase standards and writing better specs for spec-driven development.项目地址https://gitcode.com/gh_mirrors/agen/agent-os点击查看免费下载相关推荐DeepSeek RAG 知识库实战基于 JGit 解析 Git 仓库代码把工程代码库构建为可检索的向量知识库DeepSeek RAG 知识库实战基于 JGit 解析 Git 仓库代码把工程代码库构建为可检索的向量知识库 本篇是《DeepSeek RAG 知识库》第文档教程后端把隐性知识编码进仓库learn-harness-engineering 的 Agent 可发现知识工程 SOP 实践把隐性知识编码进仓库learn harness engineering 的 Agent 可发现知识工程 SOP 实践 导读 在长周期 AI Agent 开发中Agent Skills 实战指南用 openJiuwen 把专业工作方法沉淀为可复用能力Agent Skills 实战指南用 openJiuwen 把专业工作方法沉淀为可复用能力 Agent Skills 是 openJiuwen / Jiuwe人工智能AI AgentAgent 框架大模型工具调用RAG提示工程强化学习上一篇探索式实战本地部署AI视频剪辑工具完全指南下一篇如何快速清理磁盘空间dupeGuru重复文件查找工具终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考