refactor(multi): update multiple files - #8
Conversation
HelloWorldU
left a comment
There was a problem hiding this comment.
[自审] 当前状态非 ready,跳过审阅
注:GitHub 不允许 PR 作者 approve 自己的 PR,此评论仅作为审阅记录。
HelloWorldU
left a comment
There was a problem hiding this comment.
[自审] 当前状态非 ready,跳过审阅
注:GitHub 不允许 PR 作者 approve 自己的 PR,此评论仅作为审阅记录。
HelloWorldU
left a comment
There was a problem hiding this comment.
[自审] 审阅发现潜在问题,kimi 输出如下:
注:GitHub 不允许 PR 作者 approve 自己的 PR,此评论仅作为审阅记录。
HelloWorldU
left a comment
There was a problem hiding this comment.
[自审] 审阅发现潜在问题,kimi 输出如下:
经审阅,发现以下问题:
1. 🐛 Bug / 安全隐患:syncState() 直接传递 this.state 引用
private syncState() {
this.emit({ type: 'agent-state', agentId: this.state.id, state: this.state })
}这里将 this.state 引用直接作为事件负载发出。如果 Store 端(或其他监听方)对接收到的 state 进行任何修改(如增量更新时直接赋值、修改 reviews 数组等),会直接污染 Agent Engine 的内部状态,导致不可预期的副作用。
建议:发送深拷贝,如:
private syncState() {
this.emit({ type: 'agent-state', agentId: this.state.id, state: structuredClone(this.state) })
}或至少进行浅拷贝并冻结嵌套对象。
2. ⚠️ 规范/一致性问题:Diff 末尾截断,无法完整审阅
Diff 在以下位置截断:
@@ -779,6 +789,7 @@ expo最后一个 hunk 的内容未提供,无法判断第 789 行附近的变更是否正确(可能涉及另一个 syncState() 调用点或其他逻辑)。建议补全 diff 后再做最终确认。
3. ✅ 正面反馈:状态更新顺序调整正确
将以下模式:
this.setStatus('completed')
this.state.prStatus = 'merged'
this.state.reviews = []调整为:
this.state.prStatus = 'merged'
this.state.reviews = []
this.setStatus('completed')是非常必要的。因为 setStatus() 现在内部会调用 syncState(),必须先更新关联字段再触发同步,否则 Store 会收到 status='completed' 但 prStatus 仍为旧值的不一致快照。
总结:除 state 引用传递问题需修复外,其余变更逻辑正确。请在修复引用传递问题并补全 diff 后重新提交审阅。
注:GitHub 不允许 PR 作者 approve 自己的 PR,此评论仅作为审阅记录。
接过测试 PR #8(branch agent/-rk12)并处理审阅意见: - 引入 syncState():在 setStatus / 克隆完成 / PR 创建 / 提交审阅 / 指派 reviewer 等节点,通过 agent-state 事件向 Store 推送完整状态快照 - Store 新增 agent-state handler,增量更新字段并持久化 - 审阅修复:syncState() 改为发送 structuredClone(this.state),避免 Store 端修改反向污染引擎内部状态 - 顺修 types.ts 中 agent-state 行缩进 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
kimi agent 在 workspace 调研发现的真实 bug:PR squash merge 后作者 workspace 既不 fetch / pull main,也复用同一个 branch;下次接新指令 会基于已合入但本地不知道的旧 main 创建新 PR → diff 显示「已合并的 旧 commits 又出现一遍」(污染);如果期间 main 有别的 PR 合入,几乎 必出 merge conflict(反向 diff)。 本地实测验证 5/5 关键事实(mergePr 无 git 操作 / sendInstruction 恢复不 sync / merge 用 squash / branch 终身不变 / gitDeleteRemoteBranch 无调用方)。kimi 漏说的额外发现:merged 状态下 submitForReview 走 createPullRequest 新建 PR 但 branch 没换 → 触发 GitHub squash + base 漂移的核心问题。 之前 4 次 PR 没踩坑因为每个 agent 只接一轮任务;继续派任务必发。 backlog 同时记录 user 提出的「skill 注入 vs 代码硬保证」设计哲学讨论, 作为做 #8 时的参考方向(混合:关键路径硬保证 + 辅助行为 skill 注入)。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…nMerge 排除 failed 紧跟 PR #24 (Bug #8 初版实施) 的两个潜在问题修复,外加两个附带修复: 修问题 1:conflict prefix inline 注入污染 UI - 原版 syncBranchWithMain 把 conflict 文件内容 + 解决 prompt 拼到 instruction 前面返回,sendInstruction 末尾 log('input', ...) 把整段当用户消息显示, 污染「任务指令」区 + 聊天面板出现巨大「用户气泡」装冲突文件。 - 改成 syncBranchWithMain 内部独立调 runInstructionSilent 让 kimi 静默 解决冲突 → engine sanity check + commit → 然后 sendInstruction 才用 原 instruction 跑用户任务。UI 上只看到 system log「冲突自动解决中 / 已解决 / 失败」,干净。 - finalizeMergeCommit 改为接收参数的纯函数(不再用 pendingMergeCommit / conflictFiles / conflictFileOriginals 实例字段),删掉这些字段。 - 删 sendInstruction 末尾「kimi 退出后异步触发 finalize」机制,整个 sync 流程在 syncBranchWithMain 内同步完成。 修问题 2:触发条件改为不依赖 prStatus - 原版 if (prStatus === 'merged') 触发,用户在 GitHub web 手动 merge 时 prStatus 永远不变 merged → 后续 sendInstruction 不触发 sync → base 漂移问题没解决。 - 改成每次 sendInstruction 入口都触发 syncBranchWithMain,内部 5 分钟 throttle(lastSyncCheckAt 字段)防止每条用户消息都 fetch。 附带修复: - runInstructionSilent 默认 idle 120s → 600s。kimi 不是逐 token 流式 输出,是「长 think → 一批 tool call → 一段 text」分批,60-180s 间隙 正常;之前 runReview / fix loop 经常误判卡死,PR #23 之后看到的 「kimi 卡死/超时」3 次重试很多就是这个误判。 - generateCommitAndPrBody 调用 60s → 300s(大 diff 时 commit message 生成也可能 60+s)。 - canMerge 自审 + fallback 分支过滤 status === 'failed' 的 reviewer, 改成 activeReviews.every(approved)。reviewer 自动审阅 3 次跑不起来标 failed ≠ 内容被拒,不该阻塞合并。之前 PR #24 截图 1/2 通过但被 failed reviewer 卡住合并就是这个 bug。 backlog #8 同步:标 ✅ 已实施 + 列出本轮修复细节。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
变更内容
ARCHITECTURE.md文档agent.ts逻辑engine.ts逻辑types.ts逻辑useSwarmStore.ts逻辑类型
检查项