项目说明

用户提交一条反馈，Agent 自动分类、复现、修复、验证，最后提交 Pull Request。 这一页讲清楚它能做什么、不能做什么，以及为什么站点上看不到原始内容。

处理流程

固定七步，每一步都留有可审计的执行证据

  1. 领取反馈

    原子领取，避免多实例重复处理

  2. 分类与安全

    判断是否为可自动修复的后端缺陷，并拦截注入

  3. 固定源码快照

    锁定 GitHub main 的一个 commit，全程不再变动

  4. 沙箱复现

    在隔离容器中生成测试并证明缺陷真实存在

  5. 生成修复

    只允许修改后端白名单文件

  6. 独立验证

    重跑基线、目标测试、全量测试与 DOCX 结构检查

  7. 创建 PR

    验证通过才创建；绝不自动合并或部署

Trace 为什么看不到原始内容

观测数据默认脱敏；下面是每类内容实际保留了什么

  • 用户 MarkdownSHA-256 哈希、字节数、分类摘要
  • 源码与补丁文件路径、增删行数、SHA-256
  • 模型输入输出结构化结果摘要
  • 沙箱 stdout / stderr截断后的错误码
  • 联系方式从不上传，任何环节都不出现

因此本站展示的是执行结构与判定依据， 而不是内容本身。这是设计选择，不是数据缺失。

Agent 的能力边界

只改后端白名单文件

扩展、依赖、Dockerfile 与部署配置都不在可写范围内。

断言来自登记列表

只能从已注册的 Oracle 中选择，不能提交可执行表达式。

隔离沙箱执行

所有测试与补丁在容器中运行，容器内没有任何凭据。

验证通过才建 PR

绝不自动合并、绝不自动部署，最终由人审核。

复现不了就放弃

进入 cannot_reproduce，不提交空修复凑数。

数据来源

Supabase

运行摘要、状态与用量

Langfuse

逐次调用的执行 Trace

GitHub

已合并 PR 的公开 diff