01 / 问题
Issue 描述不完整
只有现象，缺少复现步骤、运行环境或预期行为。
风险
Agent 可能误解需求，从错误的问题定义开始实现。
IssueGate 对策
查找上下文，明确列出仍需补充的信息。
AI DEVELOPER TOOLGitHub Issue Intelligence
这个 Issue，
真的准备好开发了吗？
在 Coding Agent 开始写代码之前，
先验证需求、历史上下文与代码证据，再决定是否进入开发。
✓ Public Repo✓ Read Only✓ Human Approval
LIVE EVIDENCE MAP READ ONLY
IssueEvidenceJudgementHuman confirms
01提交 GitHub Issue公开 Issue URL
02查找真实依据Hybrid RAG
03判断信息是否足够Evidence
04开发准入检查Guardrail
05告诉你下一步怎么办开发 / 补信息 / 人工确认
这个 Issue 现在真的准备好开发了吗？needs_info · HITL · ready_for_coding
本次冻结评测的安全性验证✓ 未出现过度开发✓ 未出现无依据实现方案✓ 未出现无依据引用
为什么需要 IssueGate？
Coding Agent 最危险的问题，往往不是不会写代码，而是在信息还不够的时候就开始写代码。
真实问题直接开发的风险IssueGate 对策
02 / 问题
相关代码 ≠ 修改依据
检索找到相似文件，不代表知道该怎样修改。
风险
可能改错模块，或为一个小问题扩大实现范围。
IssueGate 对策
交叉核对源码、文档、评论与历史 Issue，建立证据链。
03 / 问题
模型建议 ≠ 开发许可
生成一份方案，不能证明现在就应该开始开发。
风险
缺少代码依据、测试计划或验收标准时，结论不安全。
IssueGate 对策
用最终准入检查，把模型建议与开发许可分开。
在写代码之前，先做一次有依据的判断。
模糊 Issue真实证据开发准入安全进入开发
在线分析 / Live
判断这个 Issue，是否可以进入开发。
粘贴公开 GitHub Issue 链接。先查真实依据，再判断是进入开发、补充信息，还是交给维护者确认。
○ V5 Runtime 检测中
公开 Issue · 只读分析先看懂，再体验
等待你开始分析IssueGate 会怎样判断？
01
读取 Issue
先了解用户到底报告了什么问题。
02
查找相关信息
去源码、文档、评论和历史 Issue 找依据。
03
判断信息够不够
确认是否知道问题是什么、该改哪里、怎么验证。
04
做开发准入检查
模型觉得可以做，也要再检查代码、测试和验收条件。
05
告诉你下一步
明确应该开发、补信息、看文档，还是人工确认。
正在分析
RUNNING · 请求处理中当前请求不是 streaming。以下为流程说明，完整运行记录会在结果返回后展示。
本次请求耗时：0.0s
IssueGate 找到了哪些判断依据？
技术运行详情
分析过程
02 / 产品校准安全边界有效，
安全边界有效，
开发准入仍需校准。
22 个真实 GitHub Issue，人工逐条审核。公开判断正确的地方，也公开系统过于保守的地方。
Human-Verified Real-Issue CoreV5.6.3 · 最终冻结运行 · 非生产流量分布
人工审核真实 Issue22Human-Verified
主路线准确率63.6% 14 / 22Primary Route Accuracy
重复运行路线一致5 / 55 个案例，每例运行 3 次
DECISION SIGNAL
安全边界与开发自主性
安全违规为 0，但 ready_for_coding 为 0 / 5，说明系统仍偏保守。
主路线准确率63.6%
开发准入0 / 5
安全违规0 / 4 类
分路线准确率
需要补充信息
13 / 14needs_info允许进入开发
0 / 5ready_for_coding文档即可解答
1 / 3docs_help开发路线 0 / 5：应被放行的案例未能正确进入开发。
安全性验证
已核验在这次冻结评测中，未观察到以下四类违规。
- 过度开发0 次
- 无依据实现方案0 次
- 无依据引用0 次
- 错误确认重复 Issue0 次
安全指标为本次样本观察，不代表所有使用场景下零风险。
核心发现
安全性与自主性的权衡
系统能在信息不足时停下来，却也拦住了应当进入开发的 Issue。安全验证与路线准确率需要同时解读。
已经验证没有无依据的开发
证据约束和准入边界有效。
仍需解决有依据时也可能不行动
ready_for_coding 0 / 5 暴露了过度保守。
评测口径
最终结果由 Human Gold 对照，不用模型自评替代人工判断。
- 主路线
- 每个 Issue 的主要处理去向，用于计算 14 / 22。
- 能力标签
- 非互斥 Capability Tags，描述证据冲突、关联候选、过度开发风险等维度。
- 证据边界
- 冻结 Evidence Snapshot，避免用后来的信息解释当时的判断。
- 样本限制
- 人工审核的 22 个真实 Issue，不代表生产流量分布。
系统架构
每一个决定，
都有证据与边界。
一个单智能体，完成从问题理解到开发准入的判断。检索提供依据，规则控制边界，维护者保留最终决定。
Single-Agent · Evidence-aware · Read-only从问题，到有依据的下一步
Agent 建议 ≠ 最终开发许可输入AgentEvidencePolicy输出
GitHub Issue公开问题 · 只读输入
原始反馈可能不完整。
先理解问题，再决定需要什么依据。
单智能体状态机
Agent Core01观察
读取问题与上下文
02规划
确定证据需求
03检索
调用真实信息源
04评估
判断证据是否足够
05决策
给出下一步建议
检索与证据
Hybrid RAGGitHub Issue评论项目文档源码历史 Issue
关键词检索BM25
语义检索BGE-M3
融合排序Hybrid RRF
可回溯的证据记录Evidence Snapshot
依据返回 Agent，支持充分性判断与后续决策。
证据充分性
足够解释问题
不等于足够开始开发
确定性准入规则模型给建议，
模型给建议，
规则做准入检查。
开发准入Guardrail
逐项核验
代码依据与实现目标
实现步骤、测试与验收条件
需要人工复核
先补齐信息、核对文档或人工复核关联。
needs_infodocs_helpHuman Review · HITL允许进入 Coding Agent
准备实现与验证方案，仍由维护者确认。
ready_for_coding允许进入开发图示呈现系统职责与证据流向。单次分析会按问题和证据情况选择工具，不代表每次运行都执行全部步骤。
围绕决策组织技术，
围绕证据控制边界。
保持单智能体编排，让每一次检索、评估和停止都有清晰的审计路径。
01
Agent 编排
单智能体状态机，管理观察、规划、检索、评估与决策。
LangGraphSingle-Agent State MachinePydantic
02
后端服务
接收分析请求，承载异步执行与结构化结果。
PythonFastAPIUvicorn
03
模型能力
支持检索规划与结果合成，最终结论仍受准入约束。
DeepSeekOpenAI-compatible API
04
Hybrid RAG
结合关键词与语义检索，融合多种来源的相关证据。
BM25SQLite FTS5BGE-M3sqlite-vecHybrid RRF
05
证据与数据
读取 Issue、历史讨论、文档和源码，保留可回溯证据。
GitHub REST APIEvidence SnapshotSQLite
06
安全与评测
明确自动化边界，以人工审核基准检查路线与能力。
Evidence SufficiencyDeterministic GuardrailHITLHuman-Verified BenchmarkCapability Tags
项目介绍 IssueGate 产品设计案例
先判断是否该开发，
再让 Agent 开始工作。
从一个 GitHub Issue 分诊原型，到有证据、有边界的开发准入 Agent。这个项目的演进，始终围绕一个问题：什么时候，信息已经足够支持行动？
01
定义问题
Coding Agent 可能在问题还没说清楚时，就开始写代码。
一个 Issue 可能缺少复现步骤、预期行为或影响范围。即使检索到了相关代码，也不代表已经知道该改哪里、怎么验证，更不代表现在就应该开始开发。
产品假设
在 GitHub Issue 与 Coding Agent 之间加入一道开发准入判断：先查真实依据，再确认开发条件，最后给出下一步。
GitHub Issue
IssueGate 证据与开发准入
Coding Agent 条件满足后进入
02
沿着问题迭代
每一次变化，都回应一个具体的判断风险。
-
V1分诊原型
让判断有真实依据
- 发现问题
- 仅依靠 Issue 描述、LLM 和规则，缺少真实仓库上下文。
- 设计决策
- 把真实信息检索纳入分诊过程，为关键判断提供可核对的证据。
-
V2引入 Hybrid RAG
找到相关，不等于确认重复
- 设计决策
- 结合 BM25 与 BGE-M3，通过 Hybrid RRF 融合检索结果，让 Agent 基于仓库证据判断。
- 发现问题
- 语义相似只能说明“可能相关”，不能据此安全确认两个 Issue 重复。
-
V3相关候选与 HITL
把不确定性交还给人
- 设计决策
- 使用“可能相关”候选与人工复核，避免把检索相似度直接转成重复结论。
- 新的问题
- 评测时可见的信息可能晚于 Issue 当时的上下文，判断会受到未来信息污染。
-
V4冻结证据快照
先让评测的起点可信
- 设计决策
- 通过 Evidence Snapshot 固定证据范围，让分析建立在可追溯、可重复的上下文上。
- 发现问题
- 证据更多，并不会自动带来更安全的行动；系统仍需要区分“足够解释问题”与“足够写代码”。
-
V5证据驱动的准入
让模型建议经过最后一道检查
- 设计决策
- 引入证据充分性判断与确定性 Guardrail，检查代码依据、实现目标、测试计划和验收条件。
- 产品边界
- Agent 可以提出建议，但不能直接授予开发许可；证据不足时，应明确停下来的原因。
-
V5.6.3人工审核评测
安全边界有效，也看见了过度保守
- 评测调整
- 用主路线衡量分诊判断，用非互斥能力标签描述证据与行为，避免把不同维度混成一个类别。
- 真实发现
- 22 条人工审核 Issue 中，主路线判断正确 14 条；未出现过度开发，但
ready_for_coding仅命中 0 / 5。
03
用结果修正判断
最终冻结评测
22 条人工审核真实 Issue
安全与自主性，必须一起衡量。
安全性验证
- 过度开发
- 0 次
- 无依据实现方案
- 0 次
- 无依据引用
- 0 次
- 错误确认重复 Issue
- 0 次
开发准入判断
0 / 5
ready_for_coding 路线命中
应该进入开发的案例没有被正确放行，说明系统仍然过于保守。
整体主路线准确率为 63.6%（14 / 22）。这是人工筛选并审核的基准结果，不代表生产流量分布；安全指标为本次冻结运行中的观测结果。
查看完整评测与路线表现04
下一阶段
开发准入校准
Readiness Calibration
保住安全边界，也让有充分依据的问题获得放行。
接下来应回到被漏判的 ready_for_coding 案例，逐项检查：是证据获取不足，还是准入条件过严。沿用可追溯的证据与人工判断校准门槛，同时持续验证是否引入新的无依据开发。
这是下一阶段的产品重点，尚未作为已完成能力或新增评测结果展示。