gahow/agent-manager
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

代理实现：Feat: 实现 agent 与 human 在 PR 中的交互 #6

Merged
gahow merged 1 commits from agent/issue-5-feat-agent-human-pr into main 2026-05-06 08:53:37 +00:00
Conversation 2 Commits 1 Files Changed 9 +596 -76
gahow commented 2026-05-06 08:43:53 +00:00
Owner
Copy Link

关联 Issue：#5

合并后自动关闭：Closes #5

代理实现报告

Summary

实现了 agent-manager 对已创建 PR 中 human 评论的增量监控。worker 现在会在每轮循环中扫描处于人工评审状态的 PR，过滤掉 agent 自己发布的评论；一旦发现新的 human 评论，就把原任务重新排队，并复用原 task、PR 号、分支和 workspace 继续处理，提交新的 commit 并重新发布实现说明和评审摘要。

Files changed

  • src/agent_gitea/gitea.py：新增 PR/issue comment 数据模型、评论列表 API、评论发布时间解析，并让发评论接口返回 comment 信息。
  • src/agent_gitea/db.py：新增 pull_request_feedback 表和评论游标、pending 状态相关方法。
  • src/agent_gitea/service.py：新增 PR 评论扫描流程、PR feedback 处理流程，并接入 worker loop。
  • src/agent_gitea/rendering.py：新增 PR feedback prompt 渲染，并更新人工评审摘要文案。
  • src/agent_gitea/workspace.py：新增复用既有 PR 分支/workspace 的准备逻辑。
  • src/agent_gitea/cli.py：新增 scan-pr-feedback 命令。
  • tests/test_gitea_service.py：新增 PR 评论扫描、游标推进、复用现有 PR 更新的测试。
  • README.md、README_CN.md：补充 PR 评论交互能力和新命令说明。

Test commands run

  • uv run python -m compileall src tests
  • uv run pytest
  • uv run pytest

Test results

全部通过。最终一次 uv run pytest 结果为 25 个测试全部通过。

Known risks

  • 当前实现监控的是 Gitea issue/PR conversation comments API；如果后续需要处理代码行级 review comment 或 review approval 事件，可能还需要接入 Gitea 的 review 相关 API。
  • 为了支持后续 human 评论继续处理，PR 进入人工评审后不再立即清理 workspace；这会增加磁盘占用，需要后续在 PR 合并或关闭后补充清理策略。
  • “同一个 session”在当前项目抽象中体现为同一个任务、分支和 workspace 继续运行同一 implementer agent 命令；如果底层 Codex CLI 需要显式 session id/resume 参数，还需要在 agent command 配置层进一步建模。

Follow-up suggestions

  • 增加对 Gitea review/line comment API 的支持，覆盖更完整的 PR 评审交互。
  • 在 PR 合并、关闭或任务取消后清理对应 workspace，避免长期运行时积累过多工作目录。
  • 在任务详情命令中展示 PR feedback cursor 和 pending 状态，便于排查评论触发链路。

人工审核

此 PR 由本地 agent-manager 自动创建，但不会自动合并。
请维护者人工审核、决策并手动合并。

关联 Issue：#5 合并后自动关闭：Closes #5 ## 代理实现报告 ## Summary 实现了 agent-manager 对已创建 PR 中 human 评论的增量监控。worker 现在会在每轮循环中扫描处于人工评审状态的 PR，过滤掉 agent 自己发布的评论；一旦发现新的 human 评论，就把原任务重新排队，并复用原 task、PR 号、分支和 workspace 继续处理，提交新的 commit 并重新发布实现说明和评审摘要。 ## Files changed - `src/agent_gitea/gitea.py`：新增 PR/issue comment 数据模型、评论列表 API、评论发布时间解析，并让发评论接口返回 comment 信息。 - `src/agent_gitea/db.py`：新增 `pull_request_feedback` 表和评论游标、pending 状态相关方法。 - `src/agent_gitea/service.py`：新增 PR 评论扫描流程、PR feedback 处理流程，并接入 worker loop。 - `src/agent_gitea/rendering.py`：新增 PR feedback prompt 渲染，并更新人工评审摘要文案。 - `src/agent_gitea/workspace.py`：新增复用既有 PR 分支/workspace 的准备逻辑。 - `src/agent_gitea/cli.py`：新增 `scan-pr-feedback` 命令。 - `tests/test_gitea_service.py`：新增 PR 评论扫描、游标推进、复用现有 PR 更新的测试。 - `README.md`、`README_CN.md`：补充 PR 评论交互能力和新命令说明。 ## Test commands run - `uv run python -m compileall src tests` - `uv run pytest` - `uv run pytest` ## Test results 全部通过。最终一次 `uv run pytest` 结果为 25 个测试全部通过。 ## Known risks - 当前实现监控的是 Gitea issue/PR conversation comments API；如果后续需要处理代码行级 review comment 或 review approval 事件，可能还需要接入 Gitea 的 review 相关 API。 - 为了支持后续 human 评论继续处理，PR 进入人工评审后不再立即清理 workspace；这会增加磁盘占用，需要后续在 PR 合并或关闭后补充清理策略。 - “同一个 session”在当前项目抽象中体现为同一个任务、分支和 workspace 继续运行同一 implementer agent 命令；如果底层 Codex CLI 需要显式 session id/resume 参数，还需要在 agent command 配置层进一步建模。 ## Follow-up suggestions - 增加对 Gitea review/line comment API 的支持，覆盖更完整的 PR 评审交互。 - 在 PR 合并、关闭或任务取消后清理对应 workspace，避免长期运行时积累过多工作目录。 - 在任务详情命令中展示 PR feedback cursor 和 pending 状态，便于排查评论触发链路。 ## 人工审核 此 PR 由本地 agent-manager 自动创建，但不会自动合并。 请维护者人工审核、决策并手动合并。
gahow added 1 commit 2026-05-06 08:43:53 +00:00
agent: implement issue #5 - Feat: 实现 agent 与 human 在 PR 中的交互 d227443e90
gahow commented 2026-05-06 08:46:09 +00:00
Author
Owner
Copy Link

Verdict

REQUEST_CHANGES

Summary

该实现新增了 PR 评论扫描、反馈游标、复用已有 PR 分支继续运行 implementer/reviewer 的主流程，并补充了 happy path 测试。整体方向符合 issue 目标，但当前实现仍有两个会影响真实人机交互可靠性的 correctness 问题：处理反馈期间新出现的人类评论可能被游标永久跳过；不需要代码改动的人工反馈会被强制提交，导致任务失败。

Correctness

src/agent_gitea/service.py:330 到 src/agent_gitea/service.py:334 在反馈处理结束时把 cursor 推进到“处理前已拉取评论 + 后续 agent 评论”的最大 id。若人类在 implementer/reviewer 运行期间又发了评论，且该评论 id 小于后续 reviewer/summary 评论 id，这条评论没有出现在 comments 列表里，却会被新的 cursor 覆盖，之后不会再被扫描到。这会造成 PR 中真实的人类反馈丢失。

src/agent_gitea/service.py:302 到 src/agent_gitea/service.py:304 对 PR feedback 路径直接调用 commit_changes，没有像初始实现路径那样先检查 diff，也没有允许“仅回复、无需代码改动”的结果。反馈 prompt 明确写了“Create code changes only when needed”，因此人类评论如果是问题、确认、解释请求或 agent 判断无需改代码，当前路径会因为没有 staged changes 进入 FAILED，而不是正常回复并回到 HUMAN_REVIEW_READY。

另外，拆分 _run_initial_implementation 后，原先 cleanup_on_success 的清理逻辑不再被调用。虽然保留 workspace 有利于后续反馈，但配置项仍存在，且 prepare_existing_branch 已支持 workspace 缺失时重新 clone；当前行为与配置语义不一致，需要明确修复或更新配置/文档语义。

Scope Control

改动基本集中在 PR 评论交互链路，范围可接受。README/CLI/DB/Gitea client/service/tests 都是为该功能服务。

范围风险在于当前只扫描 issue/PR 顶层 comments，不处理 PR review comments 或 inline code comments。如果 issue 预期中的“PR 中交互”包括行内 review，这一实现范围不足，需要产品层确认。

Test Evidence

我运行了 uv run pytest，结果通过：25 passed。

新增测试覆盖了：发现新 human 评论并重新排队、只有 bot 评论时推进 cursor、pending feedback 路径复用已有 PR 并推送后续 commit。

测试缺口：没有覆盖处理期间新增 human 评论的竞态；没有覆盖 PR feedback 无代码 diff 的场景；没有覆盖 PR review/inline comments；没有覆盖 cleanup_on_success=True 的行为。

Risks

真实 PR 讨论中，人类可能在 agent 处理期间继续追加评论；当前 cursor 推进方式会静默漏处理这类评论，风险较高。

真实反馈不一定都要求代码变更。强制 commit 会把正常的人类交互变成任务失败，降低可用性，也可能需要人工介入恢复任务。

如果部署方依赖 cleanup_on_success 控制磁盘占用，本 PR 会改变运行时资源管理行为。

Required Human Checks

请确认 issue #5 的范围是否要求支持 Gitea 的 PR review/inline comments，还是仅要求支持 PR 顶层 issue comments。

请确认 cleanup_on_success 在支持 PR 后续反馈后应如何定义：继续清理并在反馈时重新 clone，还是为了交互体验强制保留 workspace 并废弃/调整该配置。

Suggested PR Comment

建议先修改后再合并。当前实现的主流程和测试方向是对的，但有两个真实使用中会出问题的点：

  1. PR feedback 处理结束时 cursor 会推进到后续 agent 评论的最大 id；如果人类在 agent 处理期间又发了新评论，这条评论可能被永久跳过。
  2. feedback 路径无论是否有代码改动都会强制 commit；但 prompt 允许“仅在需要时修改代码”，所以解释类/确认类评论会因为无 diff 直接让任务失败。

另外请明确 cleanup_on_success 在这个功能下的预期，以及是否需要支持 PR review/inline comments。

## Verdict REQUEST_CHANGES ## Summary 该实现新增了 PR 评论扫描、反馈游标、复用已有 PR 分支继续运行 implementer/reviewer 的主流程，并补充了 happy path 测试。整体方向符合 issue 目标，但当前实现仍有两个会影响真实人机交互可靠性的 correctness 问题：处理反馈期间新出现的人类评论可能被游标永久跳过；不需要代码改动的人工反馈会被强制提交，导致任务失败。 ## Correctness `src/agent_gitea/service.py:330` 到 `src/agent_gitea/service.py:334` 在反馈处理结束时把 cursor 推进到“处理前已拉取评论 + 后续 agent 评论”的最大 id。若人类在 implementer/reviewer 运行期间又发了评论，且该评论 id 小于后续 reviewer/summary 评论 id，这条评论没有出现在 `comments` 列表里，却会被新的 cursor 覆盖，之后不会再被扫描到。这会造成 PR 中真实的人类反馈丢失。 `src/agent_gitea/service.py:302` 到 `src/agent_gitea/service.py:304` 对 PR feedback 路径直接调用 `commit_changes`，没有像初始实现路径那样先检查 diff，也没有允许“仅回复、无需代码改动”的结果。反馈 prompt 明确写了“Create code changes only when needed”，因此人类评论如果是问题、确认、解释请求或 agent 判断无需改代码，当前路径会因为没有 staged changes 进入 `FAILED`，而不是正常回复并回到 `HUMAN_REVIEW_READY`。 另外，拆分 `_run_initial_implementation` 后，原先 `cleanup_on_success` 的清理逻辑不再被调用。虽然保留 workspace 有利于后续反馈，但配置项仍存在，且 `prepare_existing_branch` 已支持 workspace 缺失时重新 clone；当前行为与配置语义不一致，需要明确修复或更新配置/文档语义。 ## Scope Control 改动基本集中在 PR 评论交互链路，范围可接受。README/CLI/DB/Gitea client/service/tests 都是为该功能服务。 范围风险在于当前只扫描 issue/PR 顶层 comments，不处理 PR review comments 或 inline code comments。如果 issue 预期中的“PR 中交互”包括行内 review，这一实现范围不足，需要产品层确认。 ## Test Evidence 我运行了 `uv run pytest`，结果通过：25 passed。 新增测试覆盖了：发现新 human 评论并重新排队、只有 bot 评论时推进 cursor、pending feedback 路径复用已有 PR 并推送后续 commit。 测试缺口：没有覆盖处理期间新增 human 评论的竞态；没有覆盖 PR feedback 无代码 diff 的场景；没有覆盖 PR review/inline comments；没有覆盖 `cleanup_on_success=True` 的行为。 ## Risks 真实 PR 讨论中，人类可能在 agent 处理期间继续追加评论；当前 cursor 推进方式会静默漏处理这类评论，风险较高。 真实反馈不一定都要求代码变更。强制 commit 会把正常的人类交互变成任务失败，降低可用性，也可能需要人工介入恢复任务。 如果部署方依赖 `cleanup_on_success` 控制磁盘占用，本 PR 会改变运行时资源管理行为。 ## Required Human Checks 请确认 issue #5 的范围是否要求支持 Gitea 的 PR review/inline comments，还是仅要求支持 PR 顶层 issue comments。 请确认 `cleanup_on_success` 在支持 PR 后续反馈后应如何定义：继续清理并在反馈时重新 clone，还是为了交互体验强制保留 workspace 并废弃/调整该配置。 ## Suggested PR Comment 建议先修改后再合并。当前实现的主流程和测试方向是对的，但有两个真实使用中会出问题的点： 1. PR feedback 处理结束时 cursor 会推进到后续 agent 评论的最大 id；如果人类在 agent 处理期间又发了新评论，这条评论可能被永久跳过。 2. feedback 路径无论是否有代码改动都会强制 commit；但 prompt 允许“仅在需要时修改代码”，所以解释类/确认类评论会因为无 diff 直接让任务失败。 另外请明确 `cleanup_on_success` 在这个功能下的预期，以及是否需要支持 PR review/inline comments。
gahow commented 2026-05-06 08:46:09 +00:00
Author
Owner
Copy Link

代理评审摘要

结论：REQUEST_CHANGES

建议先修改后再合并。当前实现的主流程和测试方向是对的，但有两个真实使用中会出问题的点：

  1. PR feedback 处理结束时 cursor 会推进到后续 agent 评论的最大 id；如果人类在 agent 处理期间又发了新评论，这条评论可能被永久跳过。
  2. feedback 路径无论是否有代码改动都会强制 commit；但 prompt 允许“仅在需要时修改代码”，所以解释类/确认类评论会因为无 diff 直接让任务失败。

另外请明确 cleanup_on_success 在这个功能下的预期，以及是否需要支持 PR review/inline comments。

需要人工处理

请人工审核该 PR。agent-manager 不会自动合并、关闭 PR 或提交变更请求。

## 代理评审摘要 结论：`REQUEST_CHANGES` 建议先修改后再合并。当前实现的主流程和测试方向是对的，但有两个真实使用中会出问题的点： 1. PR feedback 处理结束时 cursor 会推进到后续 agent 评论的最大 id；如果人类在 agent 处理期间又发了新评论，这条评论可能被永久跳过。 2. feedback 路径无论是否有代码改动都会强制 commit；但 prompt 允许“仅在需要时修改代码”，所以解释类/确认类评论会因为无 diff 直接让任务失败。 另外请明确 `cleanup_on_success` 在这个功能下的预期，以及是否需要支持 PR review/inline comments。 ## 需要人工处理 请人工审核该 PR。agent-manager 不会自动合并、关闭 PR 或提交变更请求。
gahow merged commit e6162e4d12 into main 2026-05-06 08:53:37 +00:00
gahow deleted branch agent/issue-5-feat-agent-human-pr 2026-05-06 08:53:37 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
agent:ready
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
gahow
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gahow/agent-manager#6
No description provided.
Delete Branch "agent/issue-5-feat-agent-human-pr"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?