人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP Clients【免费下载链接】openworker项目地址https://gitcode.com/gh_mirrors/op/openworker点击查看免费下载本篇技术指南以 OpenWorker 仓库中 surfaces/gui/e2e-live/fixtures/persona/e2e-tester.md 这份真实的人格清单persona manifest为样本逐字段剖析 manifest 的 YAML frontmatter 格式与系统提示词正文的编写规范并结合仓库源码manifest 解析、注册表、安装快照、能力同意与e2e:live冒烟测试用例说明一个第三方人格从本地目录安装 → 启用 → 出现在选择器 → 以该人格身份运行任务的完整生命周期。读者读完可以掌握如何编写一份可被 OpenWorker 合法安装的人格清单、manifest 中每个字段的取值约束与默认行为以及这套机制如何被自动化测试当作活体验证对象。一、e2e-tester.md 是什么一份用完即弃的测试人格e2e-tester.md是 OpenWorker GUI 实时端到端测试套件e2e:live的测试夹具。它的角色定位写得很直白——frontmatter 中的tagline与descriptiontagline: Throwaway persona for the live install smoke test description: Installed by the persona-install e2e:live test; writes a file on request.也就是说这份人格不是给真实用户使用的产品功能而是专门供自动化测试安装、启用并驱动其执行写文件这类最小任务用来验证人格安装 → 生命周期管理 → 会话执行这条完整管线是否工作。它所在的目录fixtures/persona/也是测试专用目录与仓库内置的 coworker/personas/builtin/ 下各产品化人格appsec-worker、change-worker、security 等在用途上有本质区别后者是发布物前者是测试探针。二、Manifest 文件格式YAML frontmatter Markdown 正文人格清单与技能清单SKILL.md采用同一种frontmatter markdown的文件形态但字段更结构化。解析逻辑在 coworker/personas/manifest.py 的_split_frontmatter()中实现文件必须以---开头包含 YAML 元数据块---之后才是正文即系统提示词。解析是严格的——任何非法字段值都会抛出ManifestError而不是静默生成一个残缺人格。e2e-tester.md 的完整 frontmatter 如下--- id: e2e-tester name: E2E Tester icon: sparkle tagline: Throwaway persona for the live install smoke test description: Installed by the persona-install e2e:live test; writes a file on request. family: knowledge workspace: deliverable tools: - files default_permission_mode: auto ---下面逐字段对照解析源码说明其含义与约束。2.1id文件系统安全的 slugid是人格的唯一标识会直接变成受管安装目录下的目录名和注册表键因此被严格限制为文件系统安全的 slug小写字母、数字、-、_长度不超过 64 字符且不能包含路径分隔符或..防目录穿越也不能含 Windows 非法字符:*?|见manifest.py中的_ID_RE正则。若省略id解析器会从文件名推导如My Persona.md会被 slugify 为my-persona。2.2name/icon/tagline/description这些是展示性字段name为人格显示名缺省时回退到idicon是图标标识e2e-tester 用的是sparkletagline显示在会话选择器的下拉项中description用于安装时的同意摘要页与详情展示。在 persona-install.spec.ts 的测试里测试正是靠 tagline 的独特性来定位下拉项——注释里明确说明人格名 E2E Tester 在会话运行后也会出现在顶栏/侧边栏只有 tagline Throwaway persona 只出现在下拉项上因此用它作为选择器的定位锚点。2.3family与workspace遗留字段及其 shim 行为family: knowledge与workspace: deliverable是旧版字段。从源码看workspace枚举在新版本中已被忽略family仅作为遗留 shim 存在合法值code/knowledge见manifest.py的VALID_FAMILIES。shim 规则是当新的工作区特征字段未声明时family: code会映射到需要文件夹门控requires_foldertrue的画像让旧 bundle 保留原有门控而family: knowledge则对应无文件夹门控的默认画像。对 e2e-tester 而言family: knowledge意味着其派生特征为requires_folderfalse、subagentsfalse而scheduling在未显式声明时默认取not requires_folder即为true——即它不会要求用户绑定主文件夹也不启用子代理扇出但允许定时任务/自唤醒。2.4tools能力白名单tools声明该人格可用的能力清单解析时_validate_tools会与coworker/catalog.py中的CATALOG能力目录逐一比对引用未知能力会直接报错并列出已知能力集合。e2e-tester 只声明了files一项这与它的系统提示词用文件工具创建文件严格一致——最小权限的测试人格不暴露 shell、git、搜索等任何多余能力。to_agent()会通过catalog.expand()把这些能力 ID 展开为真实的 Agent 工具工厂。2.5default_permission_mode: auto声明默认权限模式default_permission_mode的合法值包括discuss、plan、interactive、custom、auto、bypass-approvals、auto-approve其中auto是bypass-approvals的遗留拼写VALID_MODES注释明确说明。不过要注意一个重要安全设计新安装的第三方人格并不会直接生效其声明的模式。在 persona-install.spec.ts 中有明确注释——New sessions start in Ask for approval regardless of the personas declared mode (a safety default for freshly-installed personas)。也就是说即使 e2e-tester 声明了auto新建会话仍默认处于Ask for approval需要逐次审批模式测试必须手动切换为 Full access 才能让写文件任务一路跑完。这是一道面向第三方人格的强制安全默认值。2.6 正文系统提示词frontmatter 之后的 Markdown 正文就是该系统提示词parse_manifest()会校验其非空manifest needs anid(or a filename to derive one from) 之外has no body 同样报错。e2e-tester 的正文只有三句话是一个刻意最小化的提示词You are the E2E Tester, a persona used only by an automated live test. When the user asks you to write a file, use your file tools to create it exactly as specified, then confirm in one short sentence. Do nothing else.它只规定了两件事收到写文件请求时用文件工具精确创建、一句话确认除此之外不做任何事。这保证了测试的可判定性——任务请求与人格行为之间的映射是确定性的测试只需检查文件内容即可断言成功。三、运行该测试人格persona-install.spec.ts 全链路真正消费这份 fixture 的是 surfaces/gui/e2e-live/persona-install.spec.ts它属于e2e:live实时套件区别于封闭式e2e套件live 套件需要真实后端与真实模型见 surfaces/gui/README.md 与 package.json 中的e2e:live脚本。该测试被注释为LIVE capstone在 CI 中排除需手动执行npm run e2e:live运行。其断言链路对应了完整的人格管线安装打开 Settings ▸ Personas选择dir安装源填入FIXTURE_DIR即fixtures/persona/点击 Install等待 Installed N persona 提示。启用 上架在人格行上勾选 Enabled启用与 In picker出现在选择器测试特意用了点击并等待回勾而非check()因为这是受控 React 复选框勾选会异步触发updatePersona重渲染。以该人格新建会话离开设置页通过 New session → Choose a persona → 按 tagline 选中 E2E Tester。权限模式切换将新建会话从默认的 Ask for approval 切换到 Full access。派发任务并断言落盘发送任务Write a file named name containing exactly: token然后用expect.poll轮询 scratch 目录等待目标文件出现且内容包含 token——以文件本身ground truth作为成功信号而不是 UI 信号注释说明非 Cowork 人格不渲染 Artifacts 栏。支撑测试的辅助函数在 surfaces/gui/e2e-live/helpers.ts 中scratchBaseIfReady()通过http://127.0.0.1:8765侧车服务带X-OpenWorker-Token认证头检查后端可用性与模型就绪状态未就绪则跳过测试newestFile()跨各会话 scratch 子目录找出指定名字的最新文件——因为每个 live 会话都有自己的 scratch 目录。整体超时设置为 150 秒轮询 15 万毫秒。四、安装与快照机制manifest 如何进入受管区测试点击 Install 后后端调用的是PersonaRegistry.install_from_dir()coworker/personas/registry.py其关键行为是快照snapshot而非引用把 manifest 复制到受管安装区state/personas-installed/id/manifest.md随行的skills/目录也会一并复制使人格的定义与用户的源目录解耦、保持稳定自洽。重新安装同一 id 的人格会覆盖快照且幂等。安装返回的是每份人格的能力同意摘要consent summary见 coworker/personas/loading.py 的consent_summary()内容包含声明的工具列表、风险等级、连接器白名单、MCP 服务器、是否可发消息由连接器推导、team 角色、推荐权限模式、推荐模型与推荐连接等。测试中出现的 Installed N persona 提示背后就是这份摘要的 UI 呈现。第三方人格安装后一律先落地为禁用 不上架直到用户在风险摘要页批准其声明能力后才被启用——测试中的勾选步骤正是模拟这一用户授权动作。更新语义也值得注意重装时若新旧能力集capability_set()含tool:*、mcp:*、connector:*、messaging、team:*等键出现增长会被视为新的能力决策需要重新同意能力不变或缩小的更新则保留用户已启用的状态。五、从这份 fixture 延伸如何编写自己的可安装人格e2e-tester.md 本身就是一个可运行的第三方人格最小样例。参考它可以总结出编写一份合格 manifest 的检查清单frontmatter 必须合法以---开头并有收尾---id遵循 slug 规则family若用遗留写法只能是code/knowledgedefault_permission_mode必须属于VALID_MODESconnectors若是all保留给内置人格第三方必须显式列出连接器 id且recommends中推荐的连接器必须落在声明白名单内否则安装时报错。工具声明必须落在 CATALOG 内声明未知能力会直接ManifestError。正文即系统提示词必须非空它决定了人格的行为契约e2e-tester 的最小契约写法非常适合测试/验证场景——行为确定、边界清晰、断言容易。不要依赖声明的权限模式新安装的人格永远从 Ask for approval 起步用户需要显式授权才能切换为全访问模式。如果希望深入探索更复杂的 manifest 形态可以参考仓库内置的 change-worker/manifest.md团队 worker 角色、requires_folder/subagents特征、模型白名单与 appsec-worker/manifest.md连接器授权 技能绑定它们展示了生产级人格的完整字段组合对应的人格清单解析、注册表生命周期与安装同意逻辑则分别在 coworker/personas/manifest.py、coworker/personas/registry.py 与 coworker/personas/loading.py 中。六、小结e2e-tester.md虽是一份只有十余行的测试用一次性人格但它恰好是 OpenWorker 人格清单格式的完整缩影严格的 frontmatter 解析、能力白名单校验、遗留字段 shim、权限模式声明与安装时安全默认值再加上安装快照、能力同意、生命周期状态与 live 测试驱动构成了一条可观察、可验证的完整人格管线。对于想要为 OpenWorker 编写或安装第三方人格的开发者这份 fixture 连同其驱动的 persona-install.spec.ts既是格式规范的最短示例也是验证整条链路是否健康的最快路径。赞分享人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP Clients【免费下载链接】openworker项目地址https://gitcode.com/gh_mirrors/op/openworker点击查看免费下载相关推荐aisuite/coworker 平台 E2E Tester Persona 全解析从 Manifest 规范到 Playwright 实装冒烟测试aisuite/coworker 平台 E2E Tester Persona 全解析从 Manifest 规范到 Playwright 实装冒烟测试 本篇技术人工智能LLM 网关Agent 框架MCP ClientsArchon 确定性 E2E 测试命令详解e2e-echo-command 命令文件格式与可验证输出契约Archon 确定性 E2E 测试命令详解e2e echo command 命令文件格式与可验证输出契约 本文以 Archon 仓库中的最小化「回声」命令 e人工智能AI Agent代码智能体工作流自动化流程编排后端前端CLISwiftFormat测试用例编写验证格式化效果SwiftFormat测试用例编写验证格式化效果 引言 你是否曾因Swift代码格式化不一致而导致团队协作效率低下是否在重构代码时担心格式化工具引入意外变更开发工具代码质量CLI上一篇解决YimMenu钩子调用原始函数异常从Detour实现到实战修复下一篇FUXA项目中图形填充条件匹配问题的分析与解决创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP Clients【免费下载链接】openworker项目地址https://gitcode.com/gh_mirrors/op/openworker点击查看免费下载本篇技术指南以 OpenWorker 仓库中 surfaces/gui/e2e-live/fixtures/persona/e2e-tester.md 这份真实的人格清单persona manifest为样本逐字段剖析 manifest 的 YAML frontmatter 格式与系统提示词正文的编写规范并结合仓库源码manifest 解析、注册表、安装快照、能力同意与e2e:live冒烟测试用例说明一个第三方人格从本地目录安装 → 启用 → 出现在选择器 → 以该人格身份运行任务的完整生命周期。读者读完可以掌握如何编写一份可被 OpenWorker 合法安装的人格清单、manifest 中每个字段的取值约束与默认行为以及这套机制如何被自动化测试当作活体验证对象。一、e2e-tester.md 是什么一份用完即弃的测试人格e2e-tester.md是 OpenWorker GUI 实时端到端测试套件e2e:live的测试夹具。它的角色定位写得很直白——frontmatter 中的tagline与descriptiontagline: Throwaway persona for the live install smoke test description: Installed by the persona-install e2e:live test; writes a file on request.也就是说这份人格不是给真实用户使用的产品功能而是专门供自动化测试安装、启用并驱动其执行写文件这类最小任务用来验证人格安装 → 生命周期管理 → 会话执行这条完整管线是否工作。它所在的目录fixtures/persona/也是测试专用目录与仓库内置的 coworker/personas/builtin/ 下各产品化人格appsec-worker、change-worker、security 等在用途上有本质区别后者是发布物前者是测试探针。二、Manifest 文件格式YAML frontmatter Markdown 正文人格清单与技能清单SKILL.md采用同一种frontmatter markdown的文件形态但字段更结构化。解析逻辑在 coworker/personas/manifest.py 的_split_frontmatter()中实现文件必须以---开头包含 YAML 元数据块---之后才是正文即系统提示词。解析是严格的——任何非法字段值都会抛出ManifestError而不是静默生成一个残缺人格。e2e-tester.md 的完整 frontmatter 如下--- id: e2e-tester name: E2E Tester icon: sparkle tagline: Throwaway persona for the live install smoke test description: Installed by the persona-install e2e:live test; writes a file on request. family: knowledge workspace: deliverable tools: - files default_permission_mode: auto ---下面逐字段对照解析源码说明其含义与约束。2.1id文件系统安全的 slugid是人格的唯一标识会直接变成受管安装目录下的目录名和注册表键因此被严格限制为文件系统安全的 slug小写字母、数字、-、_长度不超过 64 字符且不能包含路径分隔符或..防目录穿越也不能含 Windows 非法字符:*?|见manifest.py中的_ID_RE正则。若省略id解析器会从文件名推导如My Persona.md会被 slugify 为my-persona。2.2name/icon/tagline/description这些是展示性字段name为人格显示名缺省时回退到idicon是图标标识e2e-tester 用的是sparkletagline显示在会话选择器的下拉项中description用于安装时的同意摘要页与详情展示。在 persona-install.spec.ts 的测试里测试正是靠 tagline 的独特性来定位下拉项——注释里明确说明人格名 E2E Tester 在会话运行后也会出现在顶栏/侧边栏只有 tagline Throwaway persona 只出现在下拉项上因此用它作为选择器的定位锚点。2.3family与workspace遗留字段及其 shim 行为family: knowledge与workspace: deliverable是旧版字段。从源码看workspace枚举在新版本中已被忽略family仅作为遗留 shim 存在合法值code/knowledge见manifest.py的VALID_FAMILIES。shim 规则是当新的工作区特征字段未声明时family: code会映射到需要文件夹门控requires_foldertrue的画像让旧 bundle 保留原有门控而family: knowledge则对应无文件夹门控的默认画像。对 e2e-tester 而言family: knowledge意味着其派生特征为requires_folderfalse、subagentsfalse而scheduling在未显式声明时默认取not requires_folder即为true——即它不会要求用户绑定主文件夹也不启用子代理扇出但允许定时任务/自唤醒。2.4tools能力白名单tools声明该人格可用的能力清单解析时_validate_tools会与coworker/catalog.py中的CATALOG能力目录逐一比对引用未知能力会直接报错并列出已知能力集合。e2e-tester 只声明了files一项这与它的系统提示词用文件工具创建文件严格一致——最小权限的测试人格不暴露 shell、git、搜索等任何多余能力。to_agent()会通过catalog.expand()把这些能力 ID 展开为真实的 Agent 工具工厂。2.5default_permission_mode: auto声明默认权限模式default_permission_mode的合法值包括discuss、plan、interactive、custom、auto、bypass-approvals、auto-approve其中auto是bypass-approvals的遗留拼写VALID_MODES注释明确说明。不过要注意一个重要安全设计新安装的第三方人格并不会直接生效其声明的模式。在 persona-install.spec.ts 中有明确注释——New sessions start in Ask for approval regardless of the personas declared mode (a safety default for freshly-installed personas)。也就是说即使 e2e-tester 声明了auto新建会话仍默认处于Ask for approval需要逐次审批模式测试必须手动切换为 Full access 才能让写文件任务一路跑完。这是一道面向第三方人格的强制安全默认值。2.6 正文系统提示词frontmatter 之后的 Markdown 正文就是该系统提示词parse_manifest()会校验其非空manifest needs anid(or a filename to derive one from) 之外has no body 同样报错。e2e-tester 的正文只有三句话是一个刻意最小化的提示词You are the E2E Tester, a persona used only by an automated live test. When the user asks you to write a file, use your file tools to create it exactly as specified, then confirm in one short sentence. Do nothing else.它只规定了两件事收到写文件请求时用文件工具精确创建、一句话确认除此之外不做任何事。这保证了测试的可判定性——任务请求与人格行为之间的映射是确定性的测试只需检查文件内容即可断言成功。三、运行该测试人格persona-install.spec.ts 全链路真正消费这份 fixture 的是 surfaces/gui/e2e-live/persona-install.spec.ts它属于e2e:live实时套件区别于封闭式e2e套件live 套件需要真实后端与真实模型见 surfaces/gui/README.md 与 package.json 中的e2e:live脚本。该测试被注释为LIVE capstone在 CI 中排除需手动执行npm run e2e:live运行。其断言链路对应了完整的人格管线安装打开 Settings ▸ Personas选择dir安装源填入FIXTURE_DIR即fixtures/persona/点击 Install等待 Installed N persona 提示。启用 上架在人格行上勾选 Enabled启用与 In picker出现在选择器测试特意用了点击并等待回勾而非check()因为这是受控 React 复选框勾选会异步触发updatePersona重渲染。以该人格新建会话离开设置页通过 New session → Choose a persona → 按 tagline 选中 E2E Tester。权限模式切换将新建会话从默认的 Ask for approval 切换到 Full access。派发任务并断言落盘发送任务Write a file named name containing exactly: token然后用expect.poll轮询 scratch 目录等待目标文件出现且内容包含 token——以文件本身ground truth作为成功信号而不是 UI 信号注释说明非 Cowork 人格不渲染 Artifacts 栏。支撑测试的辅助函数在 surfaces/gui/e2e-live/helpers.ts 中scratchBaseIfReady()通过http://127.0.0.1:8765侧车服务带X-OpenWorker-Token认证头检查后端可用性与模型就绪状态未就绪则跳过测试newestFile()跨各会话 scratch 子目录找出指定名字的最新文件——因为每个 live 会话都有自己的 scratch 目录。整体超时设置为 150 秒轮询 15 万毫秒。四、安装与快照机制manifest 如何进入受管区测试点击 Install 后后端调用的是PersonaRegistry.install_from_dir()coworker/personas/registry.py其关键行为是快照snapshot而非引用把 manifest 复制到受管安装区state/personas-installed/id/manifest.md随行的skills/目录也会一并复制使人格的定义与用户的源目录解耦、保持稳定自洽。重新安装同一 id 的人格会覆盖快照且幂等。安装返回的是每份人格的能力同意摘要consent summary见 coworker/personas/loading.py 的consent_summary()内容包含声明的工具列表、风险等级、连接器白名单、MCP 服务器、是否可发消息由连接器推导、team 角色、推荐权限模式、推荐模型与推荐连接等。测试中出现的 Installed N persona 提示背后就是这份摘要的 UI 呈现。第三方人格安装后一律先落地为禁用 不上架直到用户在风险摘要页批准其声明能力后才被启用——测试中的勾选步骤正是模拟这一用户授权动作。更新语义也值得注意重装时若新旧能力集capability_set()含tool:*、mcp:*、connector:*、messaging、team:*等键出现增长会被视为新的能力决策需要重新同意能力不变或缩小的更新则保留用户已启用的状态。五、从这份 fixture 延伸如何编写自己的可安装人格e2e-tester.md 本身就是一个可运行的第三方人格最小样例。参考它可以总结出编写一份合格 manifest 的检查清单frontmatter 必须合法以---开头并有收尾---id遵循 slug 规则family若用遗留写法只能是code/knowledgedefault_permission_mode必须属于VALID_MODESconnectors若是all保留给内置人格第三方必须显式列出连接器 id且recommends中推荐的连接器必须落在声明白名单内否则安装时报错。工具声明必须落在 CATALOG 内声明未知能力会直接ManifestError。正文即系统提示词必须非空它决定了人格的行为契约e2e-tester 的最小契约写法非常适合测试/验证场景——行为确定、边界清晰、断言容易。不要依赖声明的权限模式新安装的人格永远从 Ask for approval 起步用户需要显式授权才能切换为全访问模式。如果希望深入探索更复杂的 manifest 形态可以参考仓库内置的 change-worker/manifest.md团队 worker 角色、requires_folder/subagents特征、模型白名单与 appsec-worker/manifest.md连接器授权 技能绑定它们展示了生产级人格的完整字段组合对应的人格清单解析、注册表生命周期与安装同意逻辑则分别在 coworker/personas/manifest.py、coworker/personas/registry.py 与 coworker/personas/loading.py 中。六、小结e2e-tester.md虽是一份只有十余行的测试用一次性人格但它恰好是 OpenWorker 人格清单格式的完整缩影严格的 frontmatter 解析、能力白名单校验、遗留字段 shim、权限模式声明与安装时安全默认值再加上安装快照、能力同意、生命周期状态与 live 测试驱动构成了一条可观察、可验证的完整人格管线。对于想要为 OpenWorker 编写或安装第三方人格的开发者这份 fixture 连同其驱动的 persona-install.spec.ts既是格式规范的最短示例也是验证整条链路是否健康的最快路径。赞分享人工智能AI AgentAI 应用交互助手本地部署桌面应用MCP Clients【免费下载链接】openworker项目地址https://gitcode.com/gh_mirrors/op/openworker点击查看免费下载相关推荐aisuite/coworker 平台 E2E Tester Persona 全解析从 Manifest 规范到 Playwright 实装冒烟测试aisuite/coworker 平台 E2E Tester Persona 全解析从 Manifest 规范到 Playwright 实装冒烟测试 本篇技术人工智能LLM 网关Agent 框架MCP ClientsArchon 确定性 E2E 测试命令详解e2e-echo-command 命令文件格式与可验证输出契约Archon 确定性 E2E 测试命令详解e2e echo command 命令文件格式与可验证输出契约 本文以 Archon 仓库中的最小化「回声」命令 e人工智能AI Agent代码智能体工作流自动化流程编排后端前端CLISwiftFormat测试用例编写验证格式化效果SwiftFormat测试用例编写验证格式化效果 引言 你是否曾因Swift代码格式化不一致而导致团队协作效率低下是否在重构代码时担心格式化工具引入意外变更开发工具代码质量CLI上一篇解决YimMenu钩子调用原始函数异常从Detour实现到实战修复下一篇FUXA项目中图形填充条件匹配问题的分析与解决创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
