AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载Seed Architect 是 Ouroboros Agent OS 中负责把访谈Interview会话转化为不可变 Seed 规格的关键 Agent 角色——Seed 被称为工作流执行的宪法constitution承载目标、约束、验收标准与领域本体。本文以 Seed Architect 角色定义 为骨架结合seed_generator、answer_provenance、core/seed等源码实现系统讲解 provenance 标记语义、七大提取组件、验收标准AC成功契约的verify/artifacts/expect三件套写法、粒度契约判定以及 Seed 生成的歧义门槛与严格解析边界让你既能照规范手写可被执行的 Seed 提取输出也能理解底层引擎如何校验与落盘。Seed Architect 在 Agent OS 中的位置Ouroboros 的典型工作流是一条访谈门控Interview-gated流水线先通过多轮访谈把模糊的原始诉求收敛为明确需求再由 Seed Architect 从访谈逐字稿中提取结构化需求生成不可变的 Seed 规格最后执行引擎orchestrator、boundary 执行胶囊等以该 Seed 为唯一事实来源运行与评估。源码中这一转换由 seed_generator.py 的SeedGenerator承担它会调用 loader.py 的load_agent_prompt(seed-architect)加载本角色提示词并让 LLM 按提示词中的输出格式完成结构化提取见 seed_generator.py:2132。Seed 一经生成即不可变PydanticfrozenTrue方向性字段goal、constraints、acceptance_criteria在生成后不可修改作为评估与迭代的ground truth而本体ontology可在后续进化迭代中演进。相关数据模型定义在 core/seed.py运行时语义解释层把 Seed 投影为执行契约在 core/seed_contract.py。阅读访谈记录provenance 标记与观察扣留访谈中每条回答都带一个来源标记provenance markerSeed Architect 的第一步就是据此区分决策与事实[from-user]或无标记用户做出的决策decision。[from-code]、[from-repo]、[from-research]用户从别处采纳的事实adopted fact——例如现有系统的状态、查到的资料。事实不是决策只有决策才能成为需求。这条规则在源码中有严格落地answer_provenance.py 定义了OBSERVATION_PREFIXES ([from-code], [from-repo], [from-research], [from-data])classify_answer_provenance()据此把回答分类为user或observationextraction_rounds()对 observation 回答不做投影——内容根本不会出现在需求读取的回答槽位里从而在构造上杜绝把事实复述成决策。当一条被采纳的事实本应出现时你会看到占位符A: [observation withheld — an adopted fact, not a decision. It informed the questions that follow.]这是故意为之不是截断或错误。不要索取其内容、不要猜测、不要把这条注释本身当作需求——用户从该事实中提炼的需求已经存在于他自己的回答里提取那个即可。观察内容仍然完整保留在问题槽位中因为它的职责是打磨后续提问。关于问题行问题会完整展示包括复述采纳事实的问题。问题只用于让紧随其后的回答可被解读问题本身不是决策问题行里的任何内容都不能单独成为需求。需要提取的七大组件1. GOAL —— 目标清晰、具体的主要目标陈述。例如GOAL: Build a CLI task management tool in Python在 Seed 模型中对应Seed.goalmin_length1非空字符串见 core/seed.py。2. CONSTRAINTS —— 约束必须满足的硬性限制。格式为单行 JSON 字符串数组。值中可以包含任意字符包括字面|管道符绝不能用裸管道符作为列表分隔符——这正是要求 JSON 数组的原因让数据内的|存活为数据。示例CONSTRAINTS: [Python 3.12, No external database, Must work offline]对应Seed.constraints: tuple[str, ...]。解析实现在_parse_string_array_values()seed_generator.py严格模式提取时要求必须是合法 JSON 字符串数组否则走重试路径让模型重排格式宽松模式读取存量旧数据才回退到历史管道符切分。3. ACCEPTANCE_CRITERIA —— 验收标准核心具体、可度量的成功标准。格式为恰好一个非空的单行 JSON 数组每个对象恰好包含description、verify、artifacts、expect四个字段description字符串可观察的产出状态。verify字符串shell 命令或NONE。artifacts路径的 JSON 数组或字符串NONE。expect字符串输出字面量断言或NONE。单契约示例ACCEPTANCE_CRITERIA: [{description:Tasks can be created,verify:python -m pytest tests/test_tasks.py -q,artifacts:NONE,expect:NONE}]多产物示例ACCEPTANCE_CRITERIA: [{description:Build outputs exist,verify:NONE,artifacts:[dist/app,docs/User Guide.md],expect:NONE}]注意ACCEPTANCE_CRITERIA必须作为一行上的一个字段输出绝不能展开成嵌套的多行AC:行。行锚定的字段前缀GOAL:、CONSTRAINTS:等是提取器扫描的基础——seed_generator.py 甚至会先剥离某些 CLI 前端给行首加的时间戳如[13:57:34]因为这类前缀会破坏行锚定解析。verify / verify_command 语义使用恰好一条单行 shell 命令。绝不使用 heredoc 或任何多行 shell 语法、PY、cat EOF、续行脚本、未闭合的命令块都不行。AC 契约格式是一行多行命令体在落盘时会被丢弃。Python 片段用python -c .../python3 -c ...较长的检查应产出可被 pytest 发现的测试产物然后用python -m pytest -q。verify是观察者OBSERVER绝不是写入者writerrunner 会哈希命令执行前后的工作区任何创建、修改或删除了工作区文件的运行都会被拒绝workspace_mutated且重试无法修复——因为契约本身错了。字节码缓存和 Git 忽略的构建产物可豁免状态文件、fixture、日志、生成数据不可豁免。因此当被测程序会写状态JSON 存储、数据库文件、输出文档时把它复制进临时目录并在那里运行verify: t$(mktemp -d) cp app.py $t/ cd $t python3 app.py add x python3 app.py list绝不在工作区里写rm -f state.json python3 app.py ...这种先删后跑的命令。这些规则在源码层被硬校验_unsupported_verify_command_reason()拒绝含换行/回车或 POSIX heredoc 操作符/-的命令seed_generator.py检测器_contains_posix_heredoc_operator()甚至能在引号、参数展开、算术展开的上下文中正确识别嵌套 heredoc防止用EOF之类拼写绕过。artifacts / expected_artifacts 语义每个条目都是相对于运行工作区的精确可移植路径文件或目录。runner 逐字解析每个条目并要求其存在。多个条目编码为一个 JSON 数组例如artifacts:[dist/app,docs/User Guide.md]。路径内不要放逗号或反斜杠。路径分隔符统一用 POSIX/。绝不用描述性标签当路径例如schema v2 outputs、user approval record都不行。顶层含空格的文件/目录要加./前缀例如./Build Outputs嵌套路径如docs/User Guide.md本身已明确无需前缀。不知道确切路径时写artifacts: NONE并给出具体的verify命令。文件/目录存在性本身可以构成完整契约对于可能仍处于 pending 或 blocked 的有状态产物还应补充一条检查其语义状态的verify命令。路径可移植性在AcceptanceCriterionSpec的校验器中有完整实现core/seed.py拒绝空值/控制字符、NONE混入、反斜杠、逗号、绝对路径、..逃逸、Windows 保留组件CON/COM1/LPT1等、单组件超过 255 字节、完整规范化路径超过 255 可移植字节、以及含空格但无显式目录结构又未加./的歧义写法。此外还有成功契约总预算产物数 ≤ 253、每条 ≤ 2038 字符、契约总字符 ≤ 64000见 core/seed.py 与validate_ac_success_contract_values()。expect / output_assertion 语义expect只用于断言 verify 命令合并 stdoutstderr 中逐字出现的字面字符串例如OK或5 passed。绝不用条件、状态或退出码描述如exit code 0、exit 0、returns 0、success、no errors、passed、passes——退出码 0 已由 runner 另行验证。命令没有可断言的独特输出字面量时写expect: NONE。源码用正则_OUTPUT_ASSERTION_CONDITION_REcore/seed.py直接拒绝上述条件类描述且output_assertion必须与verify_command成对出现没有 verify 的断言会触发校验错误。注意只要expect非NONEverify也必须非NONE。粒度契约务必细读验收标准命名的是成品工作的状态state of the finished work——用户能亲眼确认其为真的东西实现步骤命名的则是抵达该状态的手段means of reaching that state。这是两个不同范畴只有前者属于这里——决定手段是执行引擎在运行时的工作它在掌握最终结果时比你对路径的猜测决策得更好。所以对每条标准都要问它是什么类型的东西把它和兄弟条目放在一起读能独立成立、是用户会珍视的东西 →outcome结果留在列表。只有作为向兄弟条目迈进的步骤才能被理解 → 那是该兄弟的means穿着 outcome 的外衣应并入它所服务的结果条目。把 means 留在验收标准列表里其严重性等同于缺失需求——它在任何人验证路径正确之前就锁死了执行路径。一个目标有多少条标准是该目标的属性通过做出上述判断来发现而不是预设数量。对应模型层面AcceptanceCriterionSpec提供has_success_contract属性core/seed.py——契约只添加证据绝不减少逐字稿义务也不覆盖 worker 执行结果。4. ONTOLOGY —— 本体领域模型本工作的数据结构/领域模型ONTOLOGY_NAME领域模型的名字。ONTOLOGY_DESCRIPTION本体代表什么。ONTOLOGY_FIELDS关键字段单行 JSON 对象数组每项含name、type、description。字段类型只能是string、number、boolean、array、object。对应模型OntologySchema/OntologyFieldcore/seed.py其中OntologyField.required默认true。本体是工作流各迭代轮次应保持的概念透镜但不强制规定最终输出形态。解析器_parse_ontology_fields()同时接受别名field_type与可选的布尔required。5. EVALUATION_PRINCIPLES —— 评估原则评估产出质量的准则。格式单行 JSON 对象数组每项含name、description、weight0.0–1.0以 JSON 数组承载是为了让文本里的冒号和管道符作为数据存活。示例EVALUATION_PRINCIPLES: [{name:completeness,description:All requirements implemented,weight:0.4},{name:quality,description:Code meets standards,weight:0.3}]对应EvaluationPrinciple模型core/seed.pyweight默认 1.0超范围会 clamp 到 [0.0, 1.0]_clamp_weight()处理溢出饱和、NaN、Infinity 等边界。Seed模型还容忍手写种子用纯字符串列表表达原则自动包装为principle_N对象。6. EXIT_CONDITIONS —— 退出条件指示工作流应终止的条件。格式单行 JSON 对象数组每项含name、description、criteria。对应ExitConditioncore/seed.pycriteria是evaluation_criteria的别名。7. BROWNFIELD CONTEXT —— 存量代码库上下文如适用若访谈提到现有代码库提取PROJECT_TYPEgreenfield或brownfield。CONTEXT_REFERENCES单行 JSON 对象数组每项含path、roleprimary表示要修改、reference表示只读与可选summary。对应ContextReferencecore/seed.py。EXISTING_PATTERNS必须遵循的关键模式单行 JSON 字符串数组。EXISTING_DEPENDENCIES要复用的关键依赖单行 JSON 字符串数组。对应BrownfieldContextcore/seed.pygreenfield 项目保持默认值project_typegreenfield、空引用。输出格式完整的结构化字段模板按下列精确结构输出分析结果。特别注意ACCEPTANCE_CRITERIA是一行上的一个字段绝不发出嵌套的AC:行GOAL: clear goal statement CONSTRAINTS: [constraint 1, constraint 2, ...] ACCEPTANCE_CRITERIA: [{description: Observable outcome, verify: python -m pytest -q, artifacts: [path/to/artifact], expect: NONE}] ONTOLOGY_NAME: name ONTOLOGY_DESCRIPTION: description ONTOLOGY_FIELDS: [{name: name, type: string|number|boolean|array|object, description: description}, ...] EVALUATION_PRINCIPLES: [{name: name, description: description, weight: 0.0-1.0}, ...] EXIT_CONDITIONS: [{name: name, description: description, criteria: criteria}, ...] PROJECT_TYPE: greenfield|brownfield CONTEXT_REFERENCES: [{path: path, role: primary|reference, summary: summary}, ...] EXISTING_PATTERNS: [pattern 1, pattern 2, ...] EXISTING_DEPENDENCIES: [dep 1, dep 2, ...]字段类型限string/number/boolean/array/object权重在 0.0–1.0 之间。要具体、要落到实处从对话中提取真实需求而不是通用占位符。对于 brownfield 项目必须从访谈中提取上下文引用和模式不能凭空编造。角色提示词还内置了 few-shot 示例展示多条 AC 与多条 verify 的组合写法ACCEPTANCE_CRITERIA: [{description:Task create/list flows pass automated verification,verify:python -m pytest tests/test_tasks.py -q echo OK,artifacts:NONE,expect:OK},{description:Greeting import check prints OK,verify:python -c \from hello import greet; assert greet(Alice) Hello, Alice; print(OK)\,artifacts:[hello.py],expect:OK},{description:README documents the CLI usage examples,verify:NONE,artifacts:[README.md],expect:NONE}]源码级纵深SeedGenerator 如何消费这份输出理解角色输出格式后再看生成器如何校验它有助于你一次写对歧义门槛ambiguity gateSeedGenerator.generate()在提取前先检查访谈的歧义分数必须 ≤ 0.2AMBIGUITY_THRESHOLD见 seed_generator.py不达标则返回ValidationError而非生成 Seed。forceTrue可绕过门槛但真实分数仍写入SeedMetadata.ambiguity_score保证 provenance 诚实。Gen 2 路径提供reflect_output与parent_seed则直接使用 ReflectEngine 精炼后的 AC 与本体突变跳过歧义门控。低温度提取提取用的温度固定为EXTRACTION_TEMPERATURE 0.2最大重试_MAX_EXTRACTION_RETRIES 1模型可通过OuroborosConfig的seed_generation角色或构造参数指定get_llm_model_for_role(seed_generation)。严格 JSON 边界ACCEPTANCE_CRITERIA 的解析是精确设计——acceptance_criteria_parsing.py 拒绝未知字段不会静默丢弃、拒绝重复 JSON 键、拒绝空数组、要求每个对象恰好含description/verify/artifacts/expect可选exempt携带免验证原因并拒绝声称有输出断言却没有产生它的命令的条目。POSIX 词法扫描_iter_outer_ac_field_markers()用带状态机的 POSIX shell 词法分析器扫描 verify 命令串能在单引号、双引号、转义、$()/${}/反引号替换、甚至嵌套case结构内部正确区分外层| verify:/| artifacts:字段标记与命令载荷里的同名文本防止伪造或截断见 seed_generator.py。需求蒸馏与提升策略Requirement Promotion Policy当存在确定性的需求提升策略时它以权威身份生效——只有被列入 promoted 集合的候选才能成为硬需求或验收标准参考派生与模型推断的被遗漏候选保持为假设。绝不能在没有用户明确确认的情况下把产品参考资料、术语表解释、视觉品味信号或模型猜测变成验收标准。该机制由 requirement_distillation.py 实现build_requirement_distillation()从初始上下文与访谈轮次构建保守候选投影observation 回答在候选提升这一步同样被跳过与提示词中的扣留规则一致参考感知的蒸馏还会走无 LLM 的确定性 Seed 构建路径。持久化生成的 Seed 可通过save_seed_sync()/save_seed()写入 YAML默认输出目录~/.ouroboros/seeds也可用load_seed()读回。Seed 用metadata.seed_id、version、created_at、ambiguity_score、interview_id、generation_mode等记录生成来源降级恢复路径如partial_seed_from_evidence必须声明degradedTrue与unresolved_slots否则校验失败core/seed.py。验证与测试你的输出会在哪里被检验test_seed_generator.py 对上述行为做了大量回归覆盖包括对 verify 命令中相邻单引号片段如printf%s| artifacts: literal、python -cprint(| verify: literal)的解析、对遗留管道分隔数据的宽容回退、对畸形 AC 字段的拒绝等。测试还验证了 runner 侧ParallelACExecutor以verify_command_timeout_seconds和ac_retry_attempts0执行契约时的行为——也就是说你写进verify的每条命令最终都会由执行器在运行时真实运行、哈希比对工作区变化、解析产物存在性并匹配expect字面量。写作检查清单输出前自问这条回答是用户做出的决策还是从别处采纳的事实只有前者能进需求。这条 AC 是成品状态outcome还是达成兄弟条目的手段meansmeans 必须并入它所服务的结果。verify是否单行、无 heredoc、且绝不写入工作区写状态就用mktemp -d复制后运行。artifacts是否都是精确可移植路径无逗号、无反斜杠、无描述性标签、顶层空格路径加了./expect是否是命令输出中逐字出现的字面字符串而非退出码/状态的描述所有字段是否都按单行 JSON 数组的格式输出且ACCEPTANCE_CRITERIA独占一行遵循上述规范产出的 Seed才能通过歧义门槛与严格契约校验成为后续执行与评估可信赖的宪法。赞分享AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载相关推荐SuperClaude Framework 需求分析师 Agent 实战指南从模糊想法到可验收规格的系统化需求工程SuperClaude Framework 需求分析师 Agent 实战指南从模糊想法到可验收规格的系统化需求工程 在 Claude Code 的开发流程中开发工具CLIAI 技能/插件测试人工智能AI 评测easy-vibe 需求验证实战用 The Mom Test 用户访谈方法把听起来不错变成可靠的需求证据easy vibe 需求验证实战用 The Mom Test 用户访谈方法把听起来不错变成可靠的需求证据 本篇文章基于 easy vibe 项目 Sta教程文档用 hudi-architect 对话式 Skill 设计 Hudi 表从工作负载需求到 ADR 与配置包用 hudi architect 对话式 Skill 设计 Hudi 表从工作负载需求到 ADR 与配置包 导读 本文介绍 Apache Hudi 仓库中随数据湖湖仓一体大数据数据存储上一篇dnd-kit与React Concurrent模式兼容处理并发渲染下的拖拽下一篇Qwen 通义千问开源模型实战指南从推理、量化、微调到部署的完整技术手册创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考