Compare commits
4
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
1f8ad3b99b | ||
|
|
9206e0d77c | ||
|
|
238f90e92a | ||
|
|
d3c9b4554e |
@@ -0,0 +1,86 @@
|
||||
# 智能体工作流质量改进:诊断、裁定与分期计划
|
||||
|
||||
状态:**已获实施授权(2026-10-09,六项裁定见 §3)**;owner:weichen;
|
||||
主任务:Dev 仓 `feature/agent-quality-phase01`(Phase 0+1 首个增量)。
|
||||
撰写日期:2026-10-09。诊断依据:dev 实例真实运行转录(PG pg1 13 次 run + 旧
|
||||
SQLite 53 次,共 62 条助手消息、263 次工具调用;模型 MiniMax-M2.7-highspeed,
|
||||
direct 入口),对照本机 ZCode v3.14.3 源码与 codex/opencode/pi/Kimi CLI/Cursor
|
||||
公开资料(2026-10-09 抓取)。诊断证据级别 SELF(本地观察与复算)。
|
||||
|
||||
本文件是该改进方向的主记录:目标、裁定、分期与验收以本文为准;
|
||||
各阶段实施细节与结果记在对应任务卡,不回写复述。
|
||||
|
||||
---
|
||||
|
||||
## 1. 问题陈述
|
||||
|
||||
与 codex / pi / kimi / cursor / zcode / opencode 相比,本系统直连对话路径在
|
||||
「工作细致、详细、完善」上存在可测差距。真实转录中定位到的失败链(均已复核):
|
||||
|
||||
1. **信息逐轮衰减**:跨轮上下文由界面消息有损重建——工具结果只回放 160 字
|
||||
摘要、参数截断、二进制原件占位、思考内容丢弃;上传材料只在「本轮」注入。
|
||||
后续轮次在摘要的摘要上工作,细节靠编造补齐(实测:「详细方案」中 85%/95%
|
||||
准确率、8000–10000 字等数字在原始转录中不存在;日期星期错配)。
|
||||
2. **修改模型倒挂**:交付物由一次性整段生成脚本产出(docx 无源文件),任何
|
||||
修改=整篇重写重跑(实测一轮 24 次工具调用 9 次失败、6KB 脚本重跑 8 次)。
|
||||
3. **检查失效且误报**:终轮评分的 lint 子进程无 PYTHONPATH 而静默失败(同一
|
||||
docx 带 PYTHONPATH 9 个 error,评分器里 0 个);终轮检查重评已被替代的旧
|
||||
工件导致死循环;可读性规则把表格单元格「项目概述撰写」判成栏目式标题;
|
||||
历史工件渲染格式 `[产出工件 …]` 与伪造标记检查同形,模型照抄即被拦。
|
||||
4. **最终答复与事实脱节**:composeFinal 只见 160 字摘要,产出了不存在的章节
|
||||
列表和「我会调整后再提交」类未兑现承诺。
|
||||
5. **过程性根因**:无任务级评测。任务卡验证=单测+mock,真实模型被列为非目标;
|
||||
evalgold 只有 1 条规则,eval/ab.go 无运行记录。
|
||||
|
||||
## 2. 根因归纳(按影响排序)
|
||||
|
||||
1. 上下文保真度不足(影响最大)——产品没有把内核的追加式会话记录当权威上下文。
|
||||
2. 工具与修改流程不适合交付物领域——没有「读源码→精确改→编译→看诊断」的对应物。
|
||||
3. 质量控制是事后把关而非让模型自己做好,且把关本身不可靠。
|
||||
4. 行为指引薄弱(何时建计划/失败换路/坚持到完成),工具描述只有一行。
|
||||
5. 没有以真实模型结果为准的评测回路。
|
||||
|
||||
内核能力(read/edit/grep/glob、超长落盘、压缩、会话树)大多已在 agent-native
|
||||
就位,问题主要在产品组装层(`modules/backend/internal/runtime|ctxasm|quality`)。
|
||||
|
||||
## 3. 用户裁定(2026-10-09,授权实施)
|
||||
|
||||
| # | 事项 | 裁定 |
|
||||
|---|---|---|
|
||||
| 1 | 直连对话开放工具与能力 | **开放,尽可能实现和开放所有的工具和能力**(推翻 2026-09-30 预览案「fs 工具实现但不默认提供」的默认关闭裁定) |
|
||||
| 2 | 跨轮上下文以内核会话记录为准 | **同意**(重新生成/排除/回滚映射为会话树分支操作) |
|
||||
| 3 | 交付物 Markdown 源码化 + 构建器 | **可以,但必须保留生成各类文件(docx/xlsx/pptx/pdf/图片等)的能力** |
|
||||
| 4 | composeFinal 与关键词评分降级 | **按建议**:Phase 2/3 落地后 composeFinal 默认关闭(仅异常兜底);关键词评分移出拦截路径、只作评测指标 |
|
||||
| 5 | 更强模型评测 | **可以,预算无上限** |
|
||||
| 6 | 行为面改动须附真实模型评测 | **按建议**:写入 Dev 仓 policy/delivery.md |
|
||||
|
||||
## 4. 分期与验收
|
||||
|
||||
每阶段独立任务卡 + PR;改动提示词/工具/上下文/门禁的 PR 须附 eval/live
|
||||
真实模型前后对照(裁定 6)。评测口径:`modules/backend/eval/live/`
|
||||
(golden 任务集 + 指标:工具失败率、整篇重跑数、是否读原件、计划使用率、
|
||||
检查误报/死循环、终轮与工件一致性、未核实数字)。
|
||||
|
||||
| 阶段 | 内容 | 验收 |
|
||||
|---|---|---|
|
||||
| **P0 评测基线** | eval/live 运行器 + tasks.json + 指标报告;before/after 各跑一次 | 基线报告能复现 §1 失败链 |
|
||||
| **P1 缺陷修复** | §1.3 的检查失效与误报七项 | 检查误报清零;两条死循环链消失 |
|
||||
| **P2 上下文保真** | 内核会话记录为权威跨轮上下文;窗口按模型真实窗口(token,实测校准);被清结果落盘留路径+预览;上传材料持久 `inputs/*.md`;交错思考模型回传 `<think>`;接上 9 段压缩模板 | 后续轮 100% 读原件;「更详细」不整篇重写;未核实数字显著下降 |
|
||||
| **P3 工具开放 + 交付物源码化** | 内核 read/edit/grep/glob 接入直连(沙箱=会话工作区);交付物 = Markdown 源文件 + `housestyle.build` 确定性渲染(自动 lint,诊断指向源行);写入即诊断;`housestyle.api` 签名查询;保留 run_python 全类型生成能力(裁定 3) | 工具失败率 ≤8%;修改请求整篇重建 ≤1 次;API 幽灵调用消失 |
|
||||
| **P4 行为指引** | 基座提示词「工作方法」段(建计划/失败两次换路/先查 API/坚持到完成/结论先行终稿);重写高频工具描述;计划提醒常开;按模型分提示词(先 MiniMax) | 多步任务计划使用率 ≥80%;终稿承诺未兑现清零 |
|
||||
| **P5 门禁精简** | 拦截型检查只留硬事实(工件存在/lint 零 error/引用存在);新增事实一致性检查(数字/日期/人名回溯材料);验证器按需触发+异模型 | 检查死循环 0;未核实数字显著下降 |
|
||||
| **模型 A/B** | 同一评测集换更强主模型对照(裁定 5,无预算上限) | 区分模型与 harness 各自的贡献,输出选型建议 |
|
||||
|
||||
## 5. 不在本文范围
|
||||
|
||||
- 操作系统级沙箱、多租户隔离策略(沿用现状与既有声明)。
|
||||
- 小队(squad)路径的同批改造——先修直连主路径,squad 经 A/B 对照跟进。
|
||||
- AGENTS.md/DESIGN.md 层面的仓库治理变更。
|
||||
|
||||
## 6. 记录与证据
|
||||
|
||||
- 诊断细节与复现命令:2026-10-09 会话记录(本文件只留结论与指针)。
|
||||
- before 基线:`eval-live/before-main-1ebd46e.json`(任务卡 evidence 引用)。
|
||||
- 关联:[Agent 栈总案](2026-10-02-agent-stack-completion.md)(库分期不受本文影响)、
|
||||
[文件预览与保留能力](2026-09-30-file-preview-and-reserved-capabilities.md)(其 §2.3
|
||||
的 fs 工具默认关闭裁定被本文裁定 1 推翻,以本文为准)。
|
||||
@@ -0,0 +1,124 @@
|
||||
# EXT 申请包 · G1:回合内共享检索、命令即工具、项目列表共享与执行后端接口(B-1/B-2/B-3 + B-5②)
|
||||
|
||||
状态:**proposed(2026-10-09)**;owner:weichen;需求依据 = RDM 评审与实施方案 V1.1
|
||||
(`Agent-System-RDM docs/proposals/2026-10-09-V22-review-and-implementation-plan.md` §3.3/§3.4/§5.3,
|
||||
owner 2026-10-09 Q1–Q8 批复;Q4=方案 A,Q2=暂时禁用+隔离档)。
|
||||
撰写日期:2026-10-09。配套:[扩展面兼容与演进](2026-10-01-extension-compat-policy.md)、
|
||||
[EXT 申请包 C1–C7](2026-10-08-ext-c1-c7-rdm-shared-contracts.md)(EXT-6…EXT-12)。
|
||||
|
||||
## 0. 总则
|
||||
|
||||
- 本包四条申请按既有序列顺延 **EXT-13…EXT-16**;最终编号以受理评审为准。
|
||||
- 分期(对齐 RDM 方案 §5.2):B-1(EXT-13)与 B-3(EXT-15)为 **G1 序 4 的硬前置**
|
||||
(成员智能体看不到项目知识 = R04 路径不通);B-2(EXT-14)为 G2/V0.1 端到端的硬前置
|
||||
(对话入口无法触达 `rdm.*`);B-5②(EXT-16)为 G2-8 原型的前置。
|
||||
- SurfaceVersion 影响:EXT-14 触及 `pkg/extension` 导出面(命令规格新字段)→ 需升
|
||||
SurfaceVersion 并同步 surface.txt;EXT-13/15/16 为 internal 行为扩展,不改导出面
|
||||
(EXT-16 若只加 `Options` 字段则属加法,见 §4)。
|
||||
|
||||
## 1. EXT-13(←B-1)回合内共享检索:智能体的检索遵循项目共享授权
|
||||
|
||||
- **场景**:RDM R04/R05——成员 B 的智能体在**回合内**(ReAct 循环的 `knowledge_search`
|
||||
工具与自动知识注入)必须能检索到成员 A 已发布的项目知识;现状只能看到本人 owner 的
|
||||
知识。HTTP 面(`/api/…/search`)已走 `RetrieveShared`(EXT-8 余项,Dev #269/#273),
|
||||
但回合内两条路径仍是 owner-only:
|
||||
- `internal/runmgr/runmgr.go:726-736` `runCtx.Retrieve` → `retriever.Retrieve(ctx, c.run.Owner, q)`(owner-only);
|
||||
- `internal/app/hostcaps.go:64-66` `hostcaps.search`(进程内 `Host.KnowledgeSearch` 底座)→ `pipe.Retrieve(owner)`(owner-only)。
|
||||
结果:同一个成员,页面搜索能看到共享知识,**智能体对话里看不到**——「所有用户的智能体
|
||||
应当能够看到项目级的共享信息」(用户补充材料 §2树1图)走不通。
|
||||
- **希望公开面**:组合根把 EXT-8 适配器(`Server.ProjectAuthz` 同款判定函数)注入
|
||||
runmgr 与 hostcaps:两条检索路径在本人 owner 两路(全文+向量)如常之外,追加
|
||||
「经适配器放行的共享两路」——与 HTTP 面 `rag.Pipeline.RetrieveShared` 完全同一实现与
|
||||
同一授权判定(复用 `sharedVisible`/`SearchKnowledgeShared`,不另造第二套语义)。
|
||||
进程内 `Host.KnowledgeSearch` 同步走共享版。
|
||||
- **为何组合不出**:`RetrieveShared` 已存在,但 runmgr/hostcaps 没有适配器的引用——
|
||||
适配器槽在 `internal/app/hostcaps.go` 的 `projectAuthz`,由组合根在装载扩展后注入
|
||||
Server;runmgr 的构造早于扩展装载,且 `Manager` 无该依赖。下游无法经任何公开面把
|
||||
「按 owner 判定共享」的回调递进回合执行路径。
|
||||
- **兼容方式**:适配器未注册=现状(本人两路);注册后共享命中追加、RRF 融合。
|
||||
不动 `pkg/extension` 导出面,SurfaceVersion 不变。
|
||||
- **验收**:同项目两人+另一项目一人(RDM 成员表桩):成员 B 发起对话,模型经
|
||||
`knowledge_search` 命中 A 已发布的知识切片(共享命中出现在工具结果);未授权者与
|
||||
跨项目者为零命中;`Host.KnowledgeSearch`(hostapi 与进程内两形态)行为一致;
|
||||
未注册适配器时与现状逐字节一致(回归)。
|
||||
|
||||
## 2. EXT-14(←B-2)插件命令即工具:`exposeAsTool`(Q4 方案 A)
|
||||
|
||||
- **场景**:RDM V0.1 端到端(C-11)要求「从空项目创建到生成项目建议书,全对话完成」;
|
||||
RDM 的全部能力(两树一网读写、上传、起草、追溯查询)都登记为 `rdm.*` 命令,而智能体
|
||||
回合的工具清单里没有任何插件命令——模型既不能检索笔记树,也不能发起 `rdm.draft.compose`。
|
||||
U0 §3.3/方案 §3.3 裁定走**方案 A**:命令经命令总线暴露为工具,四入口同源
|
||||
(button/card/slash/chat)自然延伸出第五入口「智能体」。
|
||||
- **希望公开面**:命令规格(`agentcommand.CommandSpec` 经 `Registry.AddCommandHandler`
|
||||
登记的 JSON)新增可选字段 `"exposeAsTool": {"risk": "low|medium|high"}`(缺省不暴露)。
|
||||
runmgr 装配工具清单时,把带该字段的命令投影为工具描述(名称=命令 id,参数=命令
|
||||
paramsSchema);模型调用该工具时,**不分发为工具执行,而是构造 `cmdbus.Request` 经
|
||||
命令总线分发**(Entrance="agent",Actor=会话 owner,ConversationID=当前会话)——
|
||||
同一审计信封、同一 HITL 内联确认卡(`risk=high` 或命令规格要求确认时照常弹卡)、
|
||||
同一危险分级。
|
||||
- **为何组合不出**:`Registry` 只有 AddSkill/AddCommand/AddCommandHandler/Note/
|
||||
RegisterResourceAuthorizer;工具注册表(`tools.Registry`)与命令总线之间没有任何
|
||||
桥接;MCP 通道(方案 B)绕过命令总线与确认卡,与 SR-E6/HITL 门禁冲突,已被 Q4 否决。
|
||||
- **兼容方式**:`pkg/extension` 命令规格加可选字段=导出面加法,SurfaceVersion 升
|
||||
(建议 2.6.0-experimental)+ surface.txt 同步。缺省(不写 exposeAsTool)=现状零差异。
|
||||
- **验收**:带 `exposeAsTool` 的 `/rdm.ping` 出现在模型工具清单且调用返回回执,
|
||||
审计信封 Entrance="agent" 与按钮入口同源;`risk=high` 的暴露命令在对话内触发内联
|
||||
确认卡;不带字段的命令不出现;RDM 侧 `rdm.trace`/`rdm.baseline` 等只读命令可在
|
||||
回合内被模型调用(成员 B 场景结合 EXT-13)。
|
||||
|
||||
## 3. EXT-15(←B-3)项目列表与建会话的共享放行(SR-G10)
|
||||
|
||||
- **场景**:RDM R03——成员 B 被加入项目后「界面自动出现该项目,可直接开始工作(新建
|
||||
对话)」。基座 `projects` 表按 owner 硬隔离(`store/projects.go:22-34`):
|
||||
- `GET /api/projects`(`server.go:438-441` `listProjects`)只返回本人 owner 的项目——成员看不到共享项目;
|
||||
- `POST /api/projects/{id}/conversations`(`store/projects.go:124-130`)校验「项目属于请求者」——成员在共享项目下建会话被 404。
|
||||
EXT-8 已放行的入口(工件三入口、SSE 项目流、检索)不含这两处。
|
||||
- **希望公开面**:这两处入口在 owner 自有判定未命中时咨询同一 EXT-8 适配器:
|
||||
`listProjects` 追加经适配器放行的项目(去重、标注 `shared: true` 字段供前端区分
|
||||
展示);`CreateConversation` 的归属校验放宽为「本人自有 **或** 适配器放行」。会话
|
||||
本身仍归属创建者(owner 不变),只是创建权扩展到成员。
|
||||
- **为何组合不出**:`ListProjects(owner)` 的 SQL 按 owner 过滤,无回调;建会话校验在
|
||||
store 层硬编码。与 C4(EXT-8)同因:纯下游无法改变基座 owner 过滤。
|
||||
- **兼容方式**:未注册适配器=现状;放行结果带审计。internal 行为扩展,SurfaceVersion
|
||||
不变。
|
||||
- **验收**:成员 B 的 `GET /api/projects` 含共享项目(shared 标注)且不含未授权项目;
|
||||
B 在共享项目下 `POST conversations` 成功、会话 owner=B;撤销成员后两者立即拒绝;
|
||||
项目拥有者视角无任何变化。
|
||||
|
||||
## 4. EXT-16(←B-5②)执行后端接口:隔离执行档(Q2 阶段二,G2-8 原型)
|
||||
|
||||
- **场景**:Q2 裁定「暂时禁用,但后续执行任务时肯定还是要代码执行能力」。v0.2.0 已
|
||||
交付启动级硬关闭(`Options.DisableExecTools`,Backend #110);隔离档是恢复执行能力的
|
||||
路径:执行的是**模型生成的代码**,须按不可信代码对待(方案 §3.4):只读系统根、仅挂
|
||||
会话工作目录与技能目录、默认无网、cgroup 资源限额、硬超时、按项目 venv 只读挂载;
|
||||
本机已实测 `bwrap --unshare-all` 可用(无特权 userns 被 AppArmor 限制,bwrap 专门
|
||||
策略放行)。
|
||||
- **希望公开面**:`internal/tools/exec_interpreter.go` 的进程启动点抽象为「执行后端」
|
||||
接口(`ExecBackend`:`Run(spec) → result`),启动参数选择后端:
|
||||
`ExecBackend = direct | sandbox`(缺省 direct=现状)。sandbox 后端以 bwrap 实现
|
||||
(资源限额经 systemd-run/cgroup v2)。`extension.Options` 增加
|
||||
`ExecBackend string`(加法;空=direct)。`DisableExecTools` 保留为最终兜底,优先级
|
||||
高于后端选择。
|
||||
- **为何组合不出**:现实现直接 `exec.Command`(`runInterpreter`),无后端抽象;沙箱
|
||||
参数组装(bind 清单、网络命名空间、限额)属平台面,下游插件无法注入。
|
||||
- **兼容方式**:缺省 direct=逐字节现状;`Options` 加字段=SurfaceVersion 升。RDM 在
|
||||
G3-7 才切换 sandbox;G1–G2 期间维持 `DisableExecTools=true`。
|
||||
- **验收**:sandbox 后端下逃逸负例全部被拦——读 `~/.secrets`、读其他会话目录、访问
|
||||
外网、fork 炸弹、超时不可杀均为拒绝/杀灭;会话工作目录内 docx 生成任务成功且产物
|
||||
可登记;direct 后端与现状一致(回归)。
|
||||
|
||||
## 5. 不在本申请包(显式排除)
|
||||
|
||||
- EXT-6/7/10/12 完整形态:仍在 C1–C7 包(EXT-6…12)受理轨道,节奏不变。
|
||||
- 提示词随执行可用性切换(`base.deliverables` 在禁用期的降级文案):基座自有任务,
|
||||
不占 EXT 编号。
|
||||
- UI 仓 nightly runner 修复:与代码无关(rolldown 原生绑定缺失),另立任务。
|
||||
|
||||
## 6. 受理建议
|
||||
|
||||
| 申请 | 内容 | 优先级 | 兼容 |
|
||||
|---|---|---|---|
|
||||
| EXT-13 回合内共享检索 | G1 序 4 硬前置(R04/R05) | **P0 最先** | 不变(internal) |
|
||||
| EXT-15 项目列表/建会话共享 | G1 序 4(R03/SR-G10) | P0 | 不变(internal) |
|
||||
| EXT-14 命令即工具 | G2/V0.1 端到端硬前置(Q4 方案 A) | P1 | 升(加字段) |
|
||||
| EXT-16 执行后端接口 | G2-8 原型(Q2 阶段二) | P1 | 升(加字段) |
|
||||
@@ -74,6 +74,7 @@ Dev 链接均指向对应任务 PR,可从其任务卡继续追溯组件 PR;
|
||||
| [N2 实施案](2026-10-07-agent-stack-n2-plan.md) | 栈总案 N2 的六 WP:上下文、协议、工具、skills、子代理、装配 | 未单列确认状态及 owner;正文称 N2 开工 | Documents [#42](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/42) 已合入;Dev [#244](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/244) 已合入(merge `7e3ba10`),闭卡 [#247](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/247)。卡内自述六 WP 落地;本索引未重放 |
|
||||
| [N3 实施案](2026-10-07-agent-stack-n3-plan.md) | 栈总案 N3:持久与可观测 | 页首未单列确认状态及 owner;正文称 N3 开工 | Documents [#43](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/43) 已合入;Dev [#248](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/248) 已合入(merge `2836a87`),闭卡 [#249](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/249)。卡内自述六 WP 落地;本索引未重放 |
|
||||
| [Q2/Q3 实施案](2026-10-07-agent-stack-q2q3-plans.md) | 栈总案 Q2 拓扑与 Q3 收敛互通 | 页首未单列确认状态及 owner | Documents [#44](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Documents/pulls/44) 已合入;Dev [#250](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/250) 采纳方案,[#251](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/251)(merge `452c00a`)与 [#253](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/pulls/253)(merge `c8ce4eb`)已合入。卡内自述 Q2/Q3 落地;本索引未重放 |
|
||||
| [智能体工作流质量改进](2026-10-09-agent-quality-improvement-plan.md) | 直连主路径质量:诊断→六项裁定→P0–P5 分期 + 模型 A/B;推翻 fs 工具默认关闭裁定 | 已获实施授权(2026-10-09 六项裁定);首个增量 feature/agent-quality-phase01 | 随本提案 PR;诊断 SELF(真实运行转录);基线报告见任务卡 |
|
||||
| [EXT 申请包 C1–C7](2026-10-08-ext-c1-c7-rdm-shared-contracts.md) | RDM 多人共享契约的基座最小扩展申请(EXT-6…EXT-12):身份停用/受管配置/授权适配器/索引发布/分发守卫/Host 工厂/投影过滤 | proposed;需求依据=RDM U0 主记录(D1–D9 裁定,2026-10-08 合入) | 随本提案 PR;每条现状证据为 SELF·源码级(Dev 34a2bbe/backend fe7c245),运行态 NOT_RUN;受理后逐条另立实现任务 |
|
||||
|
||||
原查询的 19 份原文中,14 份显式标注 owner 为 weichen。双档存储、启动配置面、跨会话读取、文件预览和
|
||||
|
||||
Reference in New Issue
Block a user