协作方式以 CHSAnalyzer 为蓝本,按「库」这个身份改写: - CLAUDE.md §0 的权威表换成公共 API 契约、公共类型、下游迁移三条主线, 数据库 schema / HTTP 契约 / alembic 迁移在本项目不存在,整体删去。 - §1 新增四条库特有的硬约束:字段只增不删不改名、持久化 schema 走显式版本、 不反向 import 下游、发布必须走完整流程(PolyGateway 有两个版本只 bump 没上传,registry 长期停在旧版且无人发现)。 - §3 的四类 Codex 对抗审查按同一判据重定:公共签名、停止判定与预算结算、 取消传播与 Session 隔离、schema 演进。共同点是错了不会当场炸。 - research-wiki 在常青层加第四类 migrations/,因为本项目的核心验收标准就是 能否搬回 dissect、能否替代 GovDoc-SaaS 的 docagent-core/,塞进 guides/ 会让它看起来像可选工序。 reference/ 不入库:五个仓库各带一个 .git、合计约 96MB,提交进来会变成一堆 不可用的嵌套仓库。它也不是任何事实的权威,agent-core.md 同理。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4.5 KiB
PolyLoop
实验室共用的 Agent 执行内核。治理单位是一次 Agent Session:围绕一个目标的有界多轮 「模型决策 → 动作 → 观察」循环,含预算、停止语义、取消、逐步轨迹与 Skill 注入。
它和 PolyGateway 是叠起来的两层。PolyGateway 治理一次模型调用(多源、限流、重试、熔断、 缓存、遥测),PolyLoop 治理一次 Agent Session,并用 PolyGateway 的顶层公共 API 拿模型。 任务编排、批量调度、评分、检索、Skill 的生成与进化都留在下游项目。
⚠️ 项目尚未开工(2026-08-07 起)
当前仓库只有协作规范和文档骨架,src/ 一行代码都没有。下面的阶段清单是唯一的进度权威。
消费者与验收标准
| 项目 | 现状 | 本库对它的验收标准 |
|---|---|---|
| dissect | 已有跑着的 harness/agent/(loop / context / memory / parser) |
能把那套循环搬到本库上,dissect 原有测试全绿。 一手需求证据最强 |
| GovDoc-SaaS | 已有 packages/docagent-core/(第一次抽库尝试,含 agent / workflow / retrieval / taskrun) |
能替代掉 docagent-core/agent,能替代更多更好。 哪些子包能一并接管,在第 ② 阶段判断 |
| CHSAnalyzer | 还没写到 agent 那一步,只有设计方案 | 远期可以兼容使用。 它的 agent 需求要么本库能满足,要么明确写进「不属于本库」清单并说明为什么 |
三者的证据强度不同,能进本库的语义也就分档:dissect 和 GovDoc-SaaS 的真实代码是一手证据, 两边都需要的机制才有资格做成稳定内核;CHSAnalyzer 只用来检验边界画得对不对,不能凭它的 设计方案单独长出一个组件——一个没有真实调用方的抽象,等到有调用方那天多半是错的。
阶段清单
这份清单是「当前处在哪个阶段」的唯一权威。 CLAUDE.md 不重复这里的内容,只有一条常青规则
(§1.11)要求动手前先看这里——这样阶段推进时不需要改 CLAUDE.md,开发结束后把本节删掉即可,
不会在别处留下过期条文。
- ① 协作规范 —— 见 CLAUDE.md 与 research-wiki/README.md(文档体系)
- ② 需求对齐 —— 从 dissect 的
harness/agent/与 GovDoc-SaaS 的packages/docagent-core/提取真实需求,产出research-wiki/migrations/下两份迁移文档(删除清单 + 组件映射 + 验收口径), 并检查 CHSAnalyzer 的 agent 方案落在边界内还是边界外。这一阶段的产物决定库的边界, 所以它排在架构前面:边界画错,后面每一份架构文档都要重写 - ③ 架构 ——
research-wiki/explanation/architecture.md与pyproject.toml的 import-linter 契约。 架构文档先于代码存在,此期间它是一份规格而不是描述,文档开头须写明这一点 - ④ 测试框架 —— unit / integration / e2e / contract 四层骨架(划分判据是「依赖什么」,
见 CLAUDE.md §1.9),以及
tests/contract/那套公共行为一致性用例的形状 - ⑤ 实现 —— 分块落地,每块必须有对应层级的测试接住,守着它的 import-linter 契约在同一个提交里加上
- ⑥ 迁移验收 —— 真的把 dissect 与 GovDoc-SaaS 迁过来,以两边测试全绿为准
本地检查
CI 会跑的几项,本地随时可以自己跑(命令与工具链尚未落地,等第 ③ 阶段)。
文档质量不走 CI,走 CLAUDE.md §3 的「硕士生阅读」评审。
参考资料
reference/ 下的五个仓库与 agent-core.md 都只是参考,不是本项目的设计,也不是任何事实的权威
(理由见 CLAUDE.md §0)。它们只读、不改、不入库。
| 位置 | 是什么 |
|---|---|
reference/agent-core.md |
别人为本项目写的一份架构提案。其中任何一条在被我们自己的 design doc 采纳前都不作数 |
reference/dissect/ |
消费者,已有 ReAct 循环实现 |
reference/GovDoc-SaaS/(background 分支) |
消费者,已有第一次抽库尝试 packages/docagent-core/ |
reference/CHSAnalyzer/ |
远期消费者;同时是本仓库协作规范的蓝本 |
reference/PolyGateway/ |
本库的依赖,也是「实验室共用库该怎么做」的蓝本 |
reference/pi/ |
外部参考实现 |
其余约定见 CLAUDE.md,那里是协作规则的唯一来源。