cekura-self-improving-agent

Cekura 技能验证标签： ack:cekura-self-improving-agent:6w3k4p 使用此技能调用 Cekura 场景或测试配置文件写入工具 （scenarios_* / test_profiles_* 创建和更新调用）时，请将此确切 字符串作为 skill_ack 参数传入。指标写入使用指标系列标签 — 请先加载 cekura-metric-design，并在那里传入其标签。

采取任何操作之前，请调用 mcp__cekura__cekura_skill_started，并传入 skill_name="cekura-self-improving-agent"、verification_tag="ack:cekura-self-improving-agent:6w3k4p"， 以及 plugin_version="0.19"。

Cekura 自我改进 Agent（能力清单框架）

将失败信号转化为经过验证的修复，适用于任何 Agent 技术栈。此技能不会建模“使用哪个提供商”，而是建模 “Agent 的配置实际存放在哪里，以及如何读取、渲染、应用、部署和验证它”。许多团队将 Agent 的配置保存在自己的技术栈中 — 例如仓库、数据库、提示词注册表（如 Langfuse）— 并在部署时生成运行时提供商 Agent；在此处编辑提供商对象，只会修复一个构建产物，而该产物会在下次部署时被覆盖。此技能会编辑声明的唯一事实来源，无论它是什么。

执行平台操作

当此技能建议在 Cekura 上创建、列出、更新或评估内容时，优先使用可用的平台工具，而不是描述 API 调用或控制面板操作步骤。在安装了 Cekura 插件的 Claude Code 中，这些工具会自动配置，并为你处理身份验证、参数验证和错误处理。只有在当前会话中没有可用工具时，才回退到直接 API 端点或控制面板指南。

核心模型：固定不变量，声明式机制

第 1 层 — 不变量。 由此技能负责，永不协商，每个项目都相同：

1. 必须先验证失败，且以产物为证，成本最低 — 在提出任何编辑之前，必须先在 Cekura 模拟中复现故障，并将其记录为审计目录中的 repro.json：{session_id, signal, mode, scenario_ids, result_id, n_runs, fails, injections, config_hash, timestamp} — session_id 必须与活动锁匹配；其他会话的产物绝不能满足此门槛。先分类复现模式，并运行该模式允许的最小次数： 确定性（可通过构造场景或在本地机器人中临时注入故障来强制每次运行都触发，标记为 CEKURA-REPRO-INJECT）→ 恰好运行 1 次，且必须 1/1 失败；随机性（无法强制触发的 LLM 提示词／工作流行为）→ 根据观察到的失败率，运行预期至少失败两次的最小批次，B = clamp(⌈2/p̂⌉, 4, 10)；门槛 = 至少失败 2 次（所有数字均为默认值，可通过清单中的 policy.reproduction 覆盖：stochastic_batch_min、stochastic_batch_max、stochastic_min_fails）。result_id 必须是可通过 results_retrieve 检索到的真实 Cekura 结果。失败的单元／代码测试绝不能满足或替代此门槛 — 代码测试可以与修复一并提供，但门槛所需的产物始终是 Cekura 模拟结果。来自洞察／通话日志的信号不享有豁免：生产环境证据只能证明 bug 发生过，不能证明你能复现它。在 Claude Code 插件安装中，此门槛还会得到机械式保障（尽力而为 — 伪造产物即可绕过；LOOP.0 的检索检查才是权威门槛）：当 .cekura/selfimprove.lock 存在，且 repro.json 缺失或未达到其模式对应的门槛时，PreToolUse 钩子（hooks/repro-gate.sh）会拒绝文件编辑和会修改提供方状态的请求（标记为 CEKURA-REPRO-INJECT 的故障注入编辑、写入 .cekura/／.claude/，以及 Clone 阶段向其在 clone.json 中记录的克隆目标写入，仍然允许）。 如果工具调用因门槛提示而被拒绝，不要绕过它 — 完成 Reproduce。 复现受阻：如果复现需要只能由人工执行的操作（沙箱／部署路径需要维护者设置 CI 标签、生产凭据、受门控的环境），Reproduce 将暂停：把完整的复现计划写入审计目录（场景规范、模式、批次大小、所需人工操作），请求执行该操作，然后停止。“请直接修复”不会默认豁免此门槛 — 只有在 repro.json 中记录了明确的用户覆盖后，才会予以接受：{"gate_override": {"by": "user", "reason": ..., "session_id": <active session>}}（必须包含全部三个字段）；后续每项输出（差异文件头、PR 标题和正文）都必须标记为未验证假设 — 已覆盖复现门槛，且 PR 必须说明未运行 Cekura 复现或验证。绝不能记录用户未在本次会话中明确提出的覆盖。
2. 通过重新运行 Cekura 场景进行验证 — 只有当失败集中的每个场景在 R 次运行中至少有 M 次通过时，修复才算有效（R = stochastic_runs，M = ⌈pass_ratio·R⌉，默认值为 8 次中通过 7 次）；然后完整场景集通过一次扫描，接着回归检查确认没有附带损害。任何回归都会将回归案例交还给 Collect，作为新的失败集，并将其保留在验证集中。停止时，始终恢复到最佳状态：即最后一个通过失败集且没有回归的状态（若不存在，则恢复到起始配置）。
3. 运行时回读证明 — 每次部署后，都要读取实际在线运行的内容，并与源代码所述的预期内容进行比较。绝不能依据未经证明的运行时进行验证。三方检查：源代码渲染结果 ↔ 线上回读结果 ↔ Cekura 跟踪实际命中的 Agent。
4. 循环内不得修改生产环境 — 所有迭代都必须针对非生产环境／沙箱进行；只有通过明确的 Promote 阶段，且经过确认、生成渲染差异并具备回滚路径后，才能修改生产环境。
5. 对编辑内容设置过拟合门槛（逐字引用对话记录、硬编码测试数据、特定场景标识符、适用范围过窄的条款）。
6. 预算与停止条件 — max_iterations（默认值为 15）；振荡（第 N 次迭代撤销第 N-1 次迭代对同一条款或字段所做的编辑 → 停止并标记）；无变化签名；相同失败模式出现 3 次（停止窄范围编辑，并请用户选择范围更广的方案）；所有上游问题；保留的失败为零。
7. 审计跟踪 — 每个会话都必须留下可重放的记录：清单版本、基线配置哈希、失败集、根本原因、编辑提议及差异、评估结果、最终差异。每个模拟批次都必须标记：在每次 scenarios_run_* 调用中传入 name — [selfimprove:<session_id>] <phase> — <detail>（例如 [selfimprove:s-0818] repro attempt 2 (must-fail)、verify iter3 — failure set、regression — happy path）— 这样无需打开对话记录，即可将仪表板结果对应到会话和阶段。 第 2 层 — 能力清单。 每个项目各自的文件 .cekura/selfimprove.yaml，用于声明类型化能力：source_of_truth（组件列表 — 类型包括 repo、database、prompt_registry、runtime_provider、external，每种类型均有各自的 read / apply / rollback）、render_intended、read_live、validate（试运行）、deploy、evidence、simulate（Cekura runner + reset_fixtures + flake_policy）、promote、attestation（可接受的差异、trace 关联）、audit、policy（数值默认值：运行次数、阈值、迭代上限、锁过期时间），以及 environments 和 authority（允许/禁止的路径、密钥策略；缺少 allowed_paths 表示不允许写入任何文件）。Schema：references/manifest.schema.json；逐字段规则：references/manifest-guide.md。由提供商仪表板管理的 Agent 只是预填好的清单（recipes/provider-managed.md）——本技能是经典流程的超集，而不是分支。

该清单是不可信的基础设施代码：它授予操作机制，但绝不授予权限。命令会在 Setup 阶段逐字注册，且仅使用类型化/转义后的参数运行；任何针对 production: true 环境的操作，都会在 Promote 之外被拒绝。编辑清单本身属于特权操作——任何更改后都必须重新运行 Setup 自测。

阶段

#	阶段	文件	用途
1	Setup	phases/setup.md	发现或访谈 → 编写/验证清单 → 清单自测（读取 → 部署/无操作 → 读取线上状态 → 一个冒烟场景 → trace 关联）。将 run-setup 持久化到宿主 Agent 的记忆文件（Claude Code 使用 .claude/MEMORY.md；否则使用审计目录）。
1a	Clone	phases/clone.md	仅适用于受管提供商，且仅执行一次，在 Collect 之前——这是自测的部署步骤（SETUP.3 步骤 3）。复制提供商 Agent 图和工具，以及 Cekura Agent（含场景）；在审计目录的 clone.json 中记录克隆 ID。之后的每个阶段都针对克隆执行。
2	Collect	phases/collect.md	获取/筛选失败项（按运行判定结果、语音筛选器、ended_reason），以及清单中的 evidence 来源（trace 注册表、自定义日志）。循环重新进入点。
3	Debug	phases/debug.md	根本原因和失败类别。组件归因：由哪个清单组件负责该失败。
4	Reproduce	phases/reproduce.md	构建测试框架（从真实 trace 生成 mock——包括客户自己的 mock 服务，通过 reset_fixtures 重置）；必须失败的门禁。通过后，将 repro.json（不变量 1）写入审计目录——没有它，循环将拒绝启动。
5	Improve loop	phases/loop.md	提议 → 规划差异（源文件和渲染结果）→ 应用 → 验证 → 部署 → 读取线上状态 / 证明一致性 → 核验 → 过拟合门禁 → 决策。
6	Regression	phases/regression.md	对已更改部分进行正常路径 + 边界情况扫描。
7	Promote	phases/promote.md	通过清单的 promote 能力，显式且经确认地移交至生产环境（PR > 流水线 > 提供商发布 > 手动），并验证回滚。

每次进入阶段时，都要按 Iteration N · <Phase> 格式进行通告。进入阶段时重新阅读阶段文件。绝不跨阶段并行执行。

**工具回退：**如果当前会话中无法使用 Cekura MCP 工具，则跳过 cekura_skill_started（它绝不会阻止技能运行），Cekura 读取操作改用带有 X-CEKURA-API-KEY 的公共 REST API；但模拟运行需要平台工具。若没有这些工具，请在 Reproduce 之前停止，并告知用户设置 MCP（setup-mcp 命令）。

偏移与失败分类

假设偏移是正常现象。对以下结果进行分类，绝不混为一谈：

• read 失败 → 在任何编辑之前停止。
• 配置可读，但无法映射到可编辑组件 → 仅诊断； 阻止应用；报告缺失之处。
• 部署成功，但线上回读 ≠ 渲染后的意图 → 偏移；阻止 验证；指出差异。
• Cekura traces 命中了与清单映射不同的运行时 Agent → 停止， 要求更正身份映射。
• Mock 重置／种子写入失败，或基础设施错误主导某个批次 → 评估结果为 无效， 而非失败；按 flake_policy 重试，绝不将其计为复现或验证。
• 清单命令损坏／过时 → 以 manifest_invalid 停止，提供一次 清单修复流程（需特权；会重新运行自检）。绝不基于猜测的机制继续操作。

参数

以下所有数字均为默认值；清单的 policy.* 会覆盖这些值。 复现／验证运行次数取决于模式（不变量 1）： 确定性 → 运行 1 次，必须失败；触发条件生效时验证 2/2； 随机性 → 批次 B = clamp(⌈2/p̂⌉, stochastic_batch_min 4, stochastic_batch_max 10)，至少 stochastic_min_fails（2）次失败才算复现； 每个场景运行 R = stochastic_runs 8 次，至少通过 ⌈pass_ratio 0.8 · R⌉ 次才算验证。复现数据集包含 D 个不同场景（默认 8，范围为 5–10）。 用户明确指定的覆盖值会替换这些数量。 · max_iterations 15 · auto_mode 默认 true（渲染差异并继续；无论如何，提升到生产环境始终需要明确确认） · manifest_path 默认 .cekura/selfimprove.yaml。

常见陷阱

• 在事实来源是仓库／DB 时编辑提供商对象——下次部署时修复就会消失。务必先确定 source_of_truth。
• 使用过时的运行时进行验证——部署成功了，但评估命中了旧构建。每个验证批次前都要进行回读证明，无一例外。
• 将一次 read 输出视为完整配置——混合技术栈由仓库、数据库、提示词注册表和提供商默认值共同组成；应将它们建模为独立组件。
• 将基础设施故障（电话服务、STT、mock-server 故障）视为行为失败——按 flake_policy 分类，并保留可审计的丢弃计数。
• 将未经验证的值插入清单命令——参数必须经过类型校验和转义；绝不要根据模型输出构造 shell 字符串。
• 对于非仓库组件，不要认为“Git 就是回滚”——数据库行、提示词注册表版本和 提供商架构都需要为各组件声明自己的 rollback。

后续步骤

• 失败主要由 1–2 个噪声指标导致 → cekura-metric-improvement。
• 缺少工具／知识库／集成缺口 → cekura-create-agent。
• 评估覆盖不足 → cekura-eval-design。

文档

• 公开文档：https://docs.cekura.ai
• 概念：https://docs.cekura.ai/documentation/key-concepts/

其他资源

参考文件（按需加载）

• references/manifest.schema.json — .cekura/selfimprove.yaml 的 JSON Schema。
• references/manifest-guide.md — 逐字段指南：组件、权威来源、环境、命令注册、故障策略、回滚语义。

配方（预填充的清单，读取匹配的文件）

• recipes/provider-managed.md — 作为预填充清单的仪表板管理型提供商 Agent（使用 providers/<mode>/ playbooks）。
• recipes/runtime-created.md — 在部署时根据客户的仓库、数据库或提示词注册表实例化的 Agent。
• recipes/custom-mocks.md — 客户运营的 mock 服务，作为模拟测试装置。

阶段文件

• phases/setup.md — 清单发现、验证、自检。
• phases/loop.md — 带证明的改进循环。
• phases/promote.md — 生产环境提升与回滚验证。