MaySii × Loop Engineering 集成可行性分析

基于 Fareed Khan "Testing 17 Agentic Loop Engineering Techniques" 逐项映射 MaySii 现状，识别可集成能力与优先级排序 · 2026-07-15

目录 1. 总览 — 覆盖率一览 2. 逐项映射（17 技术 × MaySii 现状） 3. 关键差距与集成方案 4. 推荐行动计划（按 ROI 排序） 5. 核心洞察与方法论启示

1. 总览

Fareed Khan 的 17 项技术覆盖从底层原语到生产模式的完整 Loop Engineering 栈。MaySii 作为自研 Agent Harness 系统（H = E,T,C,S,L,V），已具备大部分底层基础设施，但在度量驱动的生产模式和可验证信号闭环方面存在显著差距。

已完整实现

部分实现 / 可增强

显著差距

全新能力待建

2. 逐项映射

Part 1 Foundations & Primitives

#	技术	核心思想	覆盖度	MaySii 现状	可集成点
00	Trusted Scorer 评估器自检	在度量任何 loop 组件前，先验证 scorer 本身能正确区分 good/bad	部分	有 `evaluation/` 模块（LLM-as-Judge, VerifierSubAgent, TrajectoryAnalysis），但缺少 scorer 自检协议 — 没有"先用已知好/坏样本断言评估器本身可靠"的机制	新增 `ScorerSelfTest` 协议：known-good / known-bad 用例 + timeout 捕获 + pass@k 估计器。作为 harness 启动时的 gate：scorer 不过自检 → 不信任下游指标
01	Run Until Done 条件循环 + 真实反馈	Generate → Test → Feed real error back → Fix → Repeat until pass or cap。关键发现：有反馈 0.85 vs 无反馈 0.78，差距 8.3pp	已实现	`StreamingExecutionLoop` 实现了完整的 observe-think-act 循环；`LoopDetector` 检测卡死；多终止条件（max_steps/tokens/duration）；`SkillLearner` 在失败时做 teacher-escalation 分析	增强方向：显式区分"带执行反馈的 retry"和"盲目 retry"。当前 loop 的错误反馈来自 tool result，但缺少结构化的 `_refine_prompt` 模式（前次代码 + 真实 error traceback → 修正 prompt）。可在 `LoopDetector` 触发时注入结构化反馈而非仅终止
02	Skills & Context Engineering 立即可用的上下文注入	注入 schema/skill 让模型从"猜测"变"精确"。text-to-SQL: 0% → 95% executable	已实现	`SkillInjector` + `SkillsManager` 做语义检索注入；`ContextEngine`（DAG 4层压缩）；`ContextPersistor` 跨会话持久化；`SkillLearner` 自动从失败中提取新 skill	已经是 MaySii 的亮点。可增强：按任务类型自动选择 skill set（类似课程的 text-to-SQL 场景专用 skill），以及 skill 效果的量化度量（注入前后 pass 率对比）
03	Maker-Checker Subagents 独立验证器	Maker 写代码，Checker 从 spec 写自己的测试并运行，不看 maker 的代码。FAR 从 100% → 31%	部分	有 `subagents/`（fork/lifecycle/manager/runner）和 `VerifierSubAgent`，但 checker 目前依赖 LLM-as-Judge（"意见"验证），而非"从 spec 生成测试并执行"（"事实"验证）	核心增强：实现 `SelfTestChecker` 模式 — checker 只看 task spec（不看 maker 代码和隐藏测试），生成 assert 测试，运行它们，全过才 ACCEPT。这可将 false-accept rate 从 ~54% 降到 ~31%
04	Memory & RAG 检索增强 + 状态持久化	Closed-book 7% → RAG 100%。State rot 需 relevance thresholding 防误导	已实现	SQLite + LanceDB 混合搜索；Dreaming 三阶段记忆巩固；Wiki（Claim/Evidence 矛盾检测）；Knowledge Graph；Active Recall + 时间衰减；MMR 多样性召回；Query Expansion	记忆系统是 MaySii 最强的基础设施之一。可借鉴课程的 relevance thresholding：当 top-k 相似度低于阈值时，回退到 closed-book 而非注入低质量 grounding（防止"rotted"记忆污染回答）
05	Worktrees / Parallel Isolation 并发隔离	共享 tree: 1/6 存活 → git worktrees: 6/6 存活。并发修改必须有显式隔离 + merge 步骤	部分	`git_tool.py` 提供 git 操作能力，`subagents/` 支持并发 spawn，但没有 formal worktree isolation protocol — 多个 subagent 并发写同一文件时会丢数据	新增 `WorktreeIsolator`：每个 subagent spawn 时自动 `git worktree add` 独立分支 → 完成后 merge → 冲突检测 → 自动 resolve 或 escalate。对 MaySii 的多 agent 并行场景至关重要
06	Connectors & Tools 精确计算外置	模型不该在权重里"猜"数字。Tool 让模型从 10% → 83% 准确率	已实现	20+ 内置工具 + 8-step governed invocation（schema 校验 → RBAC → 限流 → 风险评估 → Hook → 执行 → 审计）；MCP 桥接；ReAct 通过 `exec_tool` 天然支持；`ToolIndex` 做语义工具检索	工具基础设施非常成熟。课程启发的改进：工具的 idempotency 标注（确保 retry 时不重复执行副作用操作），以及 tool result 的精确性标记（区分"模型推断"和"工具计算"的结果）

Part 2 Coordination & Operations

#	技术	核心思想	覆盖度	MaySii 现状	可集成点
07	Multi-Loop Coordination 目标所有权锁	多 loop 共享目标时 5 次碰撞 + ~1M token 浪费 → owner lock 后 0 碰撞	部分	`StateStore` 有 WorkingState/SessionState 两层，`cron/` 有 TaskChainRunner，但缺少跨 loop 的 target ownership registry — 多个并发 cron task 可能操作同一资源	新增 `TargetOwnershipLock`：任何 loop 在操作目标前注册 owner → 其他 loop 查到已 owner 则 yield。优先级机制（CI sweeper > PR babysitter > Dependency sweeper）。利用现有 StateStore 扩展即可
08	Budget / Cost / Observability token 成本可见性	每个策略的 cost per solve 必须可计算。质量/成本 Pareto 前沿找到最优操作点	已实现	`infra/session_cost.py` 做会话成本追踪；`token_estimation.py`；`observability/` 模块做 tracing 和 metrics；`ContextManager` 有 token budget awareness	增强：实现课程中的 cost-quality Pareto 分析 — 记录每个 loop 策略（single-shot / self-refine / maker-checker / orchestra）的 token 消耗和 resolve 率，可视化 Pareto 前沿，辅助决策哪种策略最划算
09	Safety & Guardrails risk router	auto_act ⇔ (verify=pass) ∧ (risk<τ)。Naive: 60.5% false-auto-act → Guardrail: 0%	已实现	8-step governed tool invocation 已有风险评估（HIGH risk 需人工确认）；`DangerousOperation` / `PermissionCheck` hook；RBAC；`exec-policy` allow/deny 规则	增强：实现 multi-axis risk router（不只 high/low 二元，而是 file_scope + reversibility + PII_presence + confidence 多维评分），动态调整 τ 阈值。当前偏工具级，可提升到 loop-action 级

Part 3 Production Patterns

Changelog Drafter
自动发布日志

#	技术	核心思想	覆盖度	MaySii 现状	可集成点
10	Daily Triage 紧急工单分拣	Embedding 分类器 recall 0.654 vs keyword 0.346，翻倍。从日常报告洪流中捞出稀有紧急 bug	差距	`cron/` 支持定时任务，`channels/` 28+ 消息通道可以接收工单，但没有自动 triage pipeline — 没有"从 GitHub Issues / JIRA / 消息流中自动按 embedding 优先级排序"的能力	新建 `patterns/triage.py`：利用现有 Memory 的 embedding 能力 + cron 调度 + channel 输入 → 自动对 incoming issues 做优先级排序 → 高优推送到指定 channel（钉钉/Slack）。复用 `prf1` 度量框架
11	Duplicate Detection 语义去重	"crash on startup" ≈ "app dies when I open it"。Embeddings R@10: 0.654 vs TF-IDF 0.560	已实现	LanceDB vector search + MMR + Query Expansion 已具备语义去重所需的全部基础设施。Wiki 系统的 contradiction detection 也是近似能力	将 embedding 去重包装为 `DuplicateDetector` pattern：新 issue 进入时 → embed → 在已有 issue 库中 retrieve → R@k 排序 → 超过阈值标记为 duplicate。可复用到工单、PR、commit message 等多个场景
12	CI Sweeper 先分类后修复	红 build 中 ~50% 是 flaky test。先 classify 再 fix → 省 ~2M token	差距	有 `exec_tool`、`test_runner_tool`、`test_generator_tool`，但没有 CI failure classifier — 不能自动判断失败是 real regression 还是 flaky test 还是 infra issue	新建 `patterns/ci_sweeper.py`：监听 CI webhook（通过 gateway）→ 用 LLM + 历史 log 做 flake/real/infra 三分类 → 仅 real regression 进入 self-refine loop → flaky 走 quarantine/retry → infra 走 escalate。复用现有 loop + tool 基础设施
13	PR Babysitter 验证器门控状态	self-report: 33% false-ready → verifier-gated: 0% false-ready。且修复了 3/6 红 PR	差距	有 `git_tool`、sub-agent 能力、evaluation 模块，但没有 PR state machine — 没有"监听 PR 状态变更 → 自动尝试修复 → 只在测试通过时标记 ready"的闭环	新建 `patterns/pr_babysitter.py`：GitHub webhook 监听 PR CI 失败 → spawn sub-agent 做 minimal fix → 运行测试（用 VerifierSubAgent）→ 通过则标记 ready-for-review，不通过则 escalate。核心复用 self-refine loop + maker-checker 模式
14	Dependency Sweeper 按风险路由更新	Naive auto-merge: 83.3% false-merge → risk-routed: 0% false-merge，safe patch 100% applied	全新	有 `security/` 模块（CSP, SSRF, EncryptedText），但没有依赖更新扫描和风险路由能力	新建 `patterns/dep_sweeper.py`：扫描 lockfile + CVE advisory → 按 (bump_type, cve_present) 路由 → patch+no_cve 自动 merge → minor 谨慎验证 → major/CVE escalate。可复用 safety guardrail 的 risk router
15	Post-Merge Cleanup 技术债务发现	Embedding 模型 recall 0.855 vs keyword 0.762，多发现 56 个真实债务（多 102 FP 但值得）	全新	没有自动技术债务检测。现有代码分析工具（`code_analysis_tool`）可做静态分析，但没有"从 commit message / diff 中语义识别 tech debt"的能力	新建 `patterns/tech_debt_scanner.py`：merge 后扫描 diff → embed commit message → 对比 debt prototype 向量 → 超过阈值标记为 SATD → 小债务自动清理 PR → 大债务开 ticket。利用现有 LanceDB 做 embedding 存储
16	Macro-F1 0.427 vs majority baseline 0.111，4倍。自动分类 commit 并生成 grouped release notes	全新	没有自动 changelog 生成能力	新建 `patterns/changelog_drafter.py`：收集 merge commits → LLM 分类（feat/fix/docs/breaking/ci/chore/perf/refactor/test）→ 按类别分组 → 生成 human-reviewable release notes。最简单的新 pattern，可快速出 MVP
17	Capstone: Orchestra 全组件编排	single agent 0.80 → orchestra 0.95（+15pp）。Run-until-done + test-running checker + best-of-N sampling 的组合	已实现	`HarnessAssembler` 已将 6 大组件（E,T,C,S,L,V）组装为 `HarnessStack`。Multi-stage 执行路径（single-shot → self-refine → sub-agent verification）本质上就是 Orchestra 模式	增强：实现课程中的 explicit 3-stage pipeline — Stage 1: greedy single-shot → Stage 2: run-until-done with feedback (cap 3) → Stage 3: best-of-4 sampling + selftest checker。以及 SWE-bench 风格的 Docker 验证 harness

3. 关键差距与集成方案

差距 A: 可验证信号闭环（贯穿全部技术）

课程核心命题："A loop is only as good as the verifiable signal it is wired to." 每个技术都用真实的、外部的、可机械验证的信号来驱动循环 — 测试通过/失败、schema 校验、执行等价性、exit code。MaySii 的 loop 虽然功能完整，但验证信号偏"软"：依赖 LLM-as-Judge（意见）而非 test execution（事实）。

集成方案：在 HarnessAssembler 中新增 VerificationSignal 抽象层，为每种任务类型注册硬验证器：

任务类型	验证信号	实现
代码生成	测试通过（exit code）	扩展 `test_runner_tool` 为 loop 内置 gate
SQL 生成	schema 校验 + 执行等价	新增 `schema_validity` + `exec_equiv` 评估器
PR 修复	CI 全绿	GitHub Actions API 轮询
依赖更新	build 通过 + 无 CVE	lockfile diff + advisory 扫描
文档/changelog	Macro-F1 分类准确率	embedding 分类器 + 已知标签集

差距 B: Maker-Checker 的"事实验证"模式

MaySii 的 VerifierSubAgent 是 LLM-as-Judge 模式（读代码给意见），课程证明这种方式的 FAR 仍有 54%。真正的跃升来自 SelfTest Checker：不看 maker 代码，从 spec 生成测试并运行（FAR 降到 31%，accept precision 88.6%）。

集成方案：在 subagents/ 中新增 SelfTestCheckerAgent，其 system prompt 只包含 task spec，输出是 assert 测试代码，执行全过才 ACCEPT。默认 REJECT。

差距 C: 生产模式（Production Patterns）

课程的 7 个生产模式（#10-#16）是将底层原语组合为端到端业务流程的模板。MaySii 有底层原语（loop + tools + memory + sub-agents + cron + channels），但没有将它们编排为可配置的业务 pattern。

集成方案：新建 src/maysii/patterns/ 模块，每个 pattern 是一个 PatternRunner 子类：

Pattern	复用的 MaySii 组件	新增逻辑
Daily Triage	cron + channels + memory(embedding) + prf1	issue 源接入、优先级阈值、推送路由
CI Sweeper	gateway(webhook) + LLM classifier + self-refine loop	flake/real/infra 分类器、quarantine 策略
PR Babysitter	github webhook + sub-agent + test_runner + git_tool	PR state machine、minimal fix 策略、escalation
Dep Sweeper	security + risk router + git_tool + cron	lockfile 扫描、CVE 查询、risk routing 规则
Tech Debt Scanner	git_tool + LanceDB(embedding) + channels	SATD prototype 向量、债务大小分类、清理 PR
Changelog Drafter	git_tool + LLM classifier + channels	commit 分类器、分组模板、human review gate

4. 推荐行动计划（按 ROI 排序）

P0 — SelfTest Checker（Maker-Checker 事实验证升级）

将 VerifierSubAgent 从"LLM 读代码给意见"升级为"从 spec 写测试并运行"。这是单一投入产出比最高的增强：FAR 从 54% 降到 31%，直接影响所有 sub-agent 验证场景的质量。

工作量估算: 2-3 天 · 影响范围: subagents/ + evaluation/ · 前置: 无

P0 — Scorer Self-Test 协议

在 harness 启动时运行 known-good / known-bad 断言，确认评估器本身可靠。这是"度量驱动"方法论的基础 — 如果 scorer 不可信，所有下游指标都没有意义。

工作量估算: 1-2 天 · 影响范围: evaluation/ + assembler · 前置: 无

P0 — Worktree Isolator（并发安全）

为 sub-agent 并发场景实现 git worktree 隔离。当前多 agent 并行写同文件会静默丢数据（课程实测 1/6 存活），这是 MaySii 多 agent 架构的隐患。

工作量估算: 3-4 天 · 影响范围: subagents/ + git_tool · 前置: 无

P1 — Target Ownership Lock（多 Loop 协调）

在 StateStore 上扩展 target ownership registry，防止多 cron task / 多 loop 操作同一目标时的碰撞和 token 浪费。

工作量估算: 2 天 · 影响范围: state_store + cron/ · 前置: 无

P1 — PR Babysitter Pattern

最实用的生产模式：自动监听 CI 失败的 PR → spawn sub-agent 修复 → verifier 门控 → 通过才标记 ready。直接复用 self-refine loop + SelfTest Checker。

工作量估算: 3-4 天 · 影响范围: 新 patterns/ 模块 · 前置: SelfTest Checker

P1 — Daily Triage Pattern

利用现有 embedding 能力 + cron + channels 实现自动工单分拣。MaySii 已有 28+ 消息通道，加上 LanceDB embedding，基础设施几乎就绪。

工作量估算: 2-3 天 · 影响范围: 新 patterns/ 模块 · 前置: 无

P1 — Relevance Thresholding（Memory 质量防护）

在 Memory retrieval 路径上加相似度阈值门控 — top-k 全低于阈值时回退 closed-book，避免注入低质量 grounding 污染回答。

工作量估算: 1 天 · 影响范围: memory/ + context/ · 前置: 无

P2 — CI Sweeper Pattern

CI 失败先分类（flake/real/infra）再修复，避免在 flaky test 上浪费 fix budget。需要先有 CI webhook 接入能力。

工作量估算: 3-4 天 · 影响范围: 新 patterns/ 模块 + gateway · 前置: PR Babysitter

P2 — Cost-Quality Pareto Dashboard

记录每种 loop 策略的 token 消耗和 resolve 率，生成 Pareto 前沿可视化。帮助运维决策：在什么场景用 single-shot，什么场景用 orchestra。

工作量估算: 2-3 天 · 影响范围: observability/ + web dashboard · 前置: 无

P2 — Changelog Drafter + Tech Debt Scanner

两个相对独立的 pattern，实现难度低。Changelog Drafter 是课程中最简单的 production pattern（commit 分类 + 分组笔记），Tech Debt Scanner 复用 LanceDB embedding。

工作量估算: 各 2 天 · 影响范围: 新 patterns/ 模块 · 前置: 无

P3 — Dependency Sweeper Pattern

按风险路由依赖更新（patch+safe → auto, minor → cautious, major/CVE → escalate）。需要 lockfile 解析和 CVE advisory 接入，工程量较大。

工作量估算: 4-5 天 · 影响范围: 新 patterns/ 模块 + security/ · 前置: 无

5. 核心洞察与方法论启示

洞察 1: "信号"比"重试"重要 10 倍。
Run-until-done loop 带真实反馈提升 8.3pp，不带反馈只提升 1.7pp — 花费几乎相同的 token。MaySii 的 LoopDetector 检测到卡死后只终止不反馈，应该改为注入结构化 error traceback 后重试。

洞察 2: "意见验证"和"事实验证"是两个量级。
LLM-as-Judge FAR 54%，SelfTest Checker FAR 31%。MaySii 的 VerifierSubAgent 当前是前者，升级到后者是最高 ROI 的单点改进。本质区别：checker 不看 maker 的代码，从 spec 独立生成测试并运行。

洞察 3: 并发隔离是被低估的安全需求。
共享 working tree 下 6 个 agent 只有 1 个存活 — 而且是静默丢失，没有任何错误报告。MaySii 的 multi-agent 架构如果没做 worktree 隔离，就存在这个隐患。

洞察 4: 底层原语 ≠ 生产价值，中间差的是"模式编排"。
MaySii 有非常成熟的底层（H=E,T,C,S,L,V 形式化架构），但缺少将原语组合为可交付业务流程的 pattern layer。课程的 7 个生产模式（Triage → Dedup → CI Sweeper → PR Babysitter → Dep Sweeper → Tech Debt → Changelog）本质上就是"原语 + 调度 + 业务规则"的固定组合。这正是 MaySii 可以新建 patterns/ 模块来补齐的。

洞察 5: 度量和报告 null result 的纪律。
课程在 Best-of-N 对当前模型没有提升时如实报告了 null result，在 F1 下降时也如实记录了。MaySii 的 observability 应增加"策略 A/B 对比"的结构化报告能力，包括 null 和 regression 的显式标注。

参考来源：
• Fareed Khan, "Testing 17 Agentic Loop Engineering Techniques for Reliable AI Agents", Jul 2026
• agentic-loop-engineering-course (GitHub, MIT License)
• MaySii 项目源码分析 (2026-07-15)