人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP Clients【免费下载链接】openworker项目地址https://gitcode.com/gh_mirrors/op/openworker点击查看免费下载openworker 在团队协作模式下内置了 Test Worker验证型 worker 角色其 manifest.md 定义了“构建者不得给自己的作品打分”这一核心原则当 SWE Lead 将实现类条目推进到 review 状态时Test Worker 会接收一条链接的验证条目独立地逐条核对验收标准最终给出带证据指针的 PASS/FAIL 判决。本文将以该 manifest 为主干结合 teams 的板面状态机、工具注册、journal 存储与测试用例完整拆解 Test Worker 的角色定位、验证方法论、工具集、判决契约及其底层实现。1. Test Worker 是什么团队中的独立验证者1.1 角色定位与核心原则在 openworker 的 agent 团队模型中worker 被分为两类构建者如 swe-worker负责实现条目验证者即 Test Worker负责独立检验构建者交付的成果是否符合条目的验收标准。Test Worker 的角色定义明确写在 manifest 中You are the teams verifier. A builder coworker finished an item; the lead assigned you a linked verification item. Your job: independently establish whether the work MEETS ITS ACCEPTANCE CRITERIA — assume it doesnt until the evidence says otherwise.这句 prompt 蕴含三条关键原则独立验证Test Worker 必须假设成果不达标直到证据证明其达标。这与 SWE Lead manifest 中 a builder never grades its own work 的验证策略完全一致见 swe-lead/manifest.md 第 5 条 VERIFY 规则当团队中有 test worker 时实现类条目应由 test worker 验证——先创建一条链接的验证条目并分配给验证者Lead 依据验证者的判决来裁决。对标准负责验收标准acceptance criteria是唯一的检查清单逐条核对不凭 diff 阅读作判断。面向 Lead 交付Test Worker 的沟通对象是 Lead 而非终端用户因此不使用 ask_user疑问转化为条目评论或当启用团队聊天时通过 post_chat 提及lead。1.2 manifest 的结构化声明Test Worker 的 manifest 采用 YAML frontmatter Markdown body 的标准结构与 SKILL.md 同构frontmatter 部分完整声明如下--- ships: false id: test-worker name: Test Worker icon: check tagline: Verifies teammates work against acceptance criteria requires_folder: true subagents: true version: 1 team: worker tools: [code_files, git, search, shell, todo] # What this worker COULD use (spec §11.6): the consent ceiling for the staffing # card and grant_connector. Workers start with nothing on; the human ticks. connectors: [github] models: [anthropic:claude-opus-4-8] default_permission_mode: interactive description: A verification coworker for teams — it independently tests what a builder coworker handed to review, against the items acceptance criteria, and delivers a pass/fail verdict with evidence. The builder never grades its own work. ---各字段含义与底层影响如下字段解析实现见 coworker/personas/manifest.py 的parse_manifest字段值说明idtest-worker角色唯一标识会作为目录名与注册键必须符合^[a-z0-9][a-z0-9_-]{0,63}$的文件系统安全 slug 约束teamworker团队身份声明取值为lead/worker。worker意味着该角色是专为在 Lead 指挥下工作而设计的板面 workertools[code_files, git, search, shell, todo]声明的能力清单经 catalog.py 的CATALOG校验并展开为实际工具详见 §3connectors[github]连接器授权 allowlistOPE-93 机制。关键语义worker 默认“什么连接器都没有”该列表只是 staffing 卡片与grant_connector的同意上限consent ceiling由人工勾选后才真正启用未声明 缺失不会泄漏未声明工具models[anthropic:claude-opus-4-8]有序模型白名单第一项为默认模型运行机器上无法跑第一项时顺延到可跑的第一项requires_foldertrue要求用户指定主工作文件夹composer/engine 据此做门控subagentstrue允许探索式 fan-out 子代理default_permission_modeinteractive默认权限模式合法值见VALID_MODESdiscuss/plan/interactive/custom/auto/bypass-approvals/auto-approveshipsfalse分发决定而非成熟度声明该角色存在于代码库但不进入发布构建内部构建通过OPENWORKER_UNSHIPPED1选入version1版本串仅作来源信息驱动重装时的 “replaces vN” 提示值得注意的细节Test Worker 的models只声明了一个模型而 swe-worker 声明了[anthropic:claude-opus-4-8, openai:gpt-5.6-sol]两个从源码看_models()会按序去重并拒绝models与旧别名recommended_models冲突的 manifest。而connectors的解析_connectors函数则强调fail closed列表之外的连接器一概拒绝第三方 bundle 声明connectors: all会被直接抛ManifestError——这是防信任滥用的安全设计。2. 验证方法论如何独立判定“达标”manifest 正文给 Test Worker 规定了五步验证纪律这是整份文档的实操核心2.1 从验收标准出发验证真实行为以被验证条目的验收标准为逐条检查清单测试真实行为——运行应用、运行测试、实际操练改动绝不只靠阅读 diff 来判断。这对应 SWE Lead 侧的要求验收标准是“Done when:”形式的 13 条简短、可独立检查的陈述机制性内容放进 description 而不是 criteria因为“一个验证者能对三条检查判 PASS/FAIL却无法对一篇论文判 PASS/FAIL”——标准写得越差验证越无从下手。2.2 缺测试工具的降级策略先项目本地安装再 request_tool缺少测试工具时的处理优先级优先项目本地安装在 workspace 内安装像普通开发者一样——npm i -D playwright、pip install pytestrequest_tool 仅用于系统级二进制项目自身无法携带的才申请该能力由 tools/connreq.py 支撑两者都不可行时验证能验证的部分并明确说出哪些检查无法执行。这与 swe-worker 的 “no silent skips” 纪律同构。2.3 媒体密集型验证截图、输出、渲染 diff验证过程刻意偏向多媒体证据截图、捕获输出、渲染对比。这些成本计入验证者自己的上下文从而保住构建者上下文用于构建。证据要以文件形式保存在 workspace 并通过路径引用绝不凭记忆描述像素。2.4 证据日志化journal_appendkindevidence边验证边记录运行了什么、看到了什么、捕获文件的引用、file:line 位置。底层由 teams/journal.py 的JournalStore.append实现其关键约束包括kind取值限定为finding/evidence/decision/note/raw见 teams/model.py 的JOURNAL_KINDS条目正文上限JOURNAL_BODY_LIMIT 16_000字符——大体积捕获应存为文件日志只记引用它的摘要“raw” 类型的捕获默认不会被读取除非显式要求避免 dump 淹没信号条目日志按 case 哈希链存储_HASHED_FIELDS与prev_hashappend-only、带 actor 归属与 taint 标记可verify_chain校验完整性。从 teams/tools.py 的journal_append工具 schema 可见它还支持entities具体事物文件路径、资源名、CVE id用于后续召回与refsfile:line、commit、url 指针两个元数据参数——这正是“证据指针”的落点。2.5 交付物是判决hand-off 评论中的 PASS/FAIL当验证条目被移动到 review 状态时Test Worker 以 hand-off 评论交付判决每条验收标准一个 PASS 或 FAIL并附证据指针结论要精炼“The lead reads conclusions, not pixels”证据要可链接FAIL 在真实时是好结果精确的失败判决哪里坏了、如何复现、证据在哪正是团队所需绝不软化失败绝不“凭感觉通过”。2.6 范围纪律与指挥链发现标准之外的 bug作为新条目提交create_item不扩张判决范围指挥steering以[Lead]/[User]标注到达[User]优先级更高团队契约同样约束 Test Worker开始即in_progress无法验证缺凭据、应用无法运行就带评论进入blocked永远不自己把条目标记为 done。3. 工具集板面动词 工作区能力3.1 工作区能力tools 字段的展开tools: [code_files, git, search, shell, todo]五项能力经 catalog.py 的CATALOG校验未知能力会抛ManifestError展开为具体工具能力 id展开内容源码依据风险等级code_files单仓库 workspace 的带行号读写、编辑工具集READ WRITE_LOCALgitgit_status/git_diff/git_log及 git 工具包READsearchgrepripgrep、感知 .gitignoreREADshellrun_shell 后台任务工具EXECtodotodo_write驱动 Progress 面板READ从 catalog.py 的实现看这些能力均在 manifest 解析时经_validate_tools与CATALOG对照确保角色不会引用不存在的工具。3.2 团队动词worker 集合的可见性边界Test Worker 的team: worker身份决定了它获得的板面动词集合。在 teams/tools.py 中LEAD_VERBS (create_item, list_items, transition, comment, assign, link) WORKER_VERBS (create_item, list_items, transition, comment, claim) JOURNAL_VERBS (journal_append, journal_read)board_tools返回的动词按actor.role过滤——worker 甚至看不到assign和link。且注释明确权限双重校验——工具层过滤只是便利store 层每次调用都会重新检查“the tool layer is convenience, the store is the gate”。worker 可用的关键动词及语义create_item创建新条目open、未分配。测试 worker 用它提交范围外的 bug 条目criteria是必填参数见_CREATE_ITEM_SCHEMA的 required 字段transition仅能把自己的条目移动到in_progress/blocked/review对应WORKER_TARGETS {IN_PROGRESS, BLOCKED, REVIEW}见 teams/model.pycomment给条目加持久、带归属的评论可附refs指针claim认领 open 且未分配的条目首次认领生效Lead 可在 digest 中看到并可 reassignjournal_append/journal_read验证证据的写入与过滤读取。3.3 板面状态机review→done 的验证门状态机定义于 teams/model.pyopen → in_progress / canceled in_progress → blocked / review / canceled blocked → in_progress / canceled review → done / in_progress / canceled done → (无出口) canceled → open关键设计review → done是验证门。worker 永远无法把条目移到 doneWORKER_TARGETS不含 DONE测试test_workers_never_mark_done在 tests/test_team_board.py 中验证了该 AuthorityErrordone 是 Lead 在 review 阶段的裁决——当团队有 test worker 时这个裁决以 test worker 的判决为基础。Test Worker 在blocked时必须以评论说明具体缺什么绝不能静默停滞。4. 与团队的协作闭环一条验证条目的生命周期将 manifest 与 Lead 侧规则swe-lead/manifest.md拼接可以得到 Test Worker 参与的一次完整验证闭环分配SWE Lead 将实现条目推进到 review 后创建一条链接的验证条目linked verification item可用link的parent/blocks关联分配给 Test Worker开始Test Worker 将验证条目移动到in_progress验证逐条对照验收标准运行真实行为测试安装项目本地测试工具截图/捕获输出为文件用journal_append(kindevidence)记录运行内容、观察结果与 file:line 引用同时用todo_write维护可见进度列表交付判决将验证条目移动到review在 hand-off 评论中给出逐标准的 PASS/FAIL 与证据指针Lead 裁决Lead 依据判决将原条目标记 done或带精确评论退回in_progressTest Worker 自身永不标记 done板面状态机强制执行见test_workers_never_mark_done测试异常路径缺凭据或应用无法运行 → 带说明评论进入blocked发现范围外 bug →create_item提交新条目open 且未分配测试test_workers_file_items_open_and_unassigned验证了该行为提交后可见但不能自分配open-claims默认策略下其他 worker 可认领lead-only策略下则严格切片隔离。整个闭环的权限骨架由 tests/test_team_board.py 覆盖worker 无法展开切片窥探他人条目test_worker_cannot_expand_its_slice_through_a_hidden_parent、无法触碰他人条目test_worker_cannot_touch_someone_elses_item、无法 assign/linktest_workers_cannot_assign_or_link、验收标准必填test_acceptance_criteria_are_required。5. 如何在实际团队中启用 Test Worker结合 manifest 语义与 swe-lead/manifest.md 的 staffing 流程实际启用步骤如下在 openworker 中创建团队会话并选择 SWE Lead 作为 lead 角色Lead 通过propose_team提出 roster为 Test Worker 指定 personatest-worker、短 callname如checks、模型与 reason用户审批后创建 worker 会话连接器决策Lead 应先调用team_options查看每个 worker 的ready/connectable/not_connected/other_connected连接器状态。Test Worker 的connectors: [github]只是同意上限——worker 默认无连接器只有用户在 staffing 卡片上勾选后才生效。由于 Test Worker 的工具集含shell可在工作区内本地安装测试框架通常无需额外连接器确实需要时才通过request_connector申请并说明理由条目到达 review 后Lead 创建链接的验证条目分配给 Test Worker依据其 PASS/FAIL 判决完成review → done或退回注意ships: falseTest Worker 不随发布构建分发内部构建需设置OPENWORKER_UNSHIPPED1才能选入见 manifest.py 对ships的注释这是分发决定而非成熟度声明。6. 设计亮点与适用边界设计亮点职责分离的制度化验证者与构建者分开把“谁也不能给自己的作品打分”从口头约定变成角色边界、状态机权限和 verdict 交付格式三层面的硬约束证据成本归属媒体密集型证据截图、输出、diff 渲染计入验证者上下文构建者上下文只用于构建——这是对多 agent 协作中上下文预算的显式管理失败是资产prompt 明确 “Never soften a fail; never pass on vibes”精确的 FAIL 判决坏了什么、如何复现、证据在哪被视为团队最需要的信息权限最小化worker 角色看不到assign/link无法标记 done无法访问他人条目切片无法自授连接器——每次调用 store 层都会复审双重校验。适用边界Test Worker 是ships: false的内部角色不会出现在公开发行版中发布构建通过OPENWORKER_UNSHIPPED1才引入它面向团队协作场景team: worker单独使用solo不具备团队资格——manifest 解析中 team 字段缺失时被视为 solo-onlystaffing 会 fail closed其验证能力依赖requires_folder: true的用户指定主文件夹与interactive默认权限模式无法执行系统级安装且项目无法携带依赖时manifest 明确要求降级为“验证能验证的并说明哪些检查未执行”因此验证覆盖率受运行环境实际约束。综上Test Worker 是 openworker 团队协作验证链条中的专职独立验证者它以验收标准为唯一清单以真实行为测试为方法以 journal 证据为支撑以逐标准 PASS/FAIL 证据指针的 verdict 为交付物从制度上保证了“构建者不给自己打分”的质量防线。其完整定义见 coworker/personas/builtin/test-worker/manifest.md底层机制可继续阅读 teams/model.py、teams/tools.py、teams/journal.py 与 tests/test_team_board.py。赞分享人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP Clients【免费下载链接】openworker项目地址https://gitcode.com/gh_mirrors/op/openworker点击查看免费下载相关推荐OmX 的 Verifier 角色深度解析基于可复现证据的完成度验证与 PASS/FAIL/PARTIAL 判定契约OmX 的 Verifier 角色深度解析基于可复现证据的完成度验证与 PASS/FAIL/PARTIAL 判定契约 导读 本文聚焦 OmXOh My co人工智能AI AgentAgent 编排Agent 工作流CLI开发工具AI 技能如何快速开始使用Valent5步连接你的手机与电脑如何快速开始使用Valent5步连接你的手机与电脑 Valent是一款功能强大的设备连接工具能够帮助用户轻松实现手机与电脑之间的连接、控制和同步。无论你是想人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP ClientsPentestGPT 如何用 --smoke-test 验证已配置的 LLM 提供商并拿到 pass/fail 矩阵PentestGPT 如何用 smoke test 验证已配置的 LLM 提供商并拿到 pass/fail 矩阵 配置好多家 LLM 提供商的 API key网络安全渗透测试人工智能大模型AI Agent自主智能体上一篇Data-Juicer项目数据集配置完全指南下一篇Phinx数据库种子(Seeding)功能详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考