【S3 Wave 3 交叉评测】Yorimi 对 BidRoom-Agent 的反馈 #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
项目理解
BidRoom Agent 面向投标和招标协作，将长篇招标文件转化为结构化要求矩阵，并强调页码引用、证据状态、合规风险和投标模拟。
项目定义五项技能：招标文件拆解、证据关联、响应草拟、合规审计和投标模拟。公开仓库提供 Agent 核心、技能包、Schema、脱敏样例和安全说明；前端、认证、数据库及完整部署平台保持私有。
值得肯定的地方
选择了明确且高价值的业务问题。
README 将痛点聚焦在长篇招标文件、资格门槛、证据散落和提交前风险发现。samples/requirement-matrix.sample.json 展示了要求、页码、证据、置信度和风险状态，输出与业务决策之间的关系较直观。
公开 Agent 核心包含真实执行代码。
agent/src/orchestrator.ts 实现文件数量和体积检查，并调用 OpenRouter；agent/src/openrouter-client.ts 配置严格 JSON Schema、文件解析插件、响应修复和安全用户哈希；agent/src/analysis.ts 对 JSON 进行解析、置信度归一化并重新计算 summary。这比仅提交流程图或提示词更有说服力。
技能包对证据和安全边界要求具体。
skills 下的 SKILL.md 对引用页码、缺失证据、资格门槛、提示注入和不得编造材料等行为进行了约束。尤其“证据不足应明确标记，而不是生成看似完整的投标答案”符合高风险业务场景。
公开与私有边界说明清楚。
MANIFEST.md 明确指出仓库不包含前端、数据库、认证和部署配置；README 也没有把脱敏样例描述成真实客户数据。这有助于避免评审误解项目开放范围。
具体问题或不清楚处
“五项技能协作/固定顺序”与公开运行方式存在表达差异。
agent/src/agent-skills.ts 将五项技能提示拼接成一个 orchestrator prompt，agent/src/orchestrator.ts 随后进行一次 OpenRouter 调用。公开实现中没有五次技能执行、技能间中间产物传递，或逐技能成功/失败状态。
因此目前更接近“一次模型调用中的五阶段提示”，而不是可独立观察的五技能编排。两种设计都合理，但文档和可验收证据应与实际实现一致。
自动化验证目前只有类型检查。
agent/package.json 仅提供 tsc --noEmit 的 check 脚本，未见单元或集成测试。文件上限、错误 JSON、缺失字段、越界置信度、提示注入、引用缺失和 provider 异常等关键路径目前缺少公开回归证据。
本地运行时验证依赖外部凭据。
Agent Core 需要 OpenRouter API Key，线上 Demo 凭据又位于私有比赛说明中。对普通交叉评审者而言，很难在不获得额外权限的情况下重复执行 README 中的核心流程。仓库虽提供输出样例，但样例与某个输入、模型版本和运行记录之间尚未形成可验证绑定。
严格 Schema 主要依赖模型供应商层。
agent/src/analysis.ts 在 JSON.parse 后主要确认 requirements 是数组，再进行归一化；本地没有对全部字段执行独立运行时 Schema 校验。虽然 OpenRouter 请求已使用 strict JSON Schema，但仍建议防御代理降级、响应修复或未来接口变化产生的不合规结果。
可验收的下一步建议
增加测试套件，至少覆盖文件数与体积边界、无效 JSON、缺失字段、置信度归一化、summary 重算、提示注入文本、缺失证据和 OpenRouter 异常；将 npm test 纳入 CI。验收标准是上述路径各有至少一个确定性测试，且无需真实客户文件。
明确五项技能的实现语义：若保留单次调用，应将其描述为“单次调用中的五阶段分析”；若希望证明技能编排，则输出逐技能的 input/output/status，并形成机器可读 agent_run。
提供无密钥复验路径，例如脱敏 tender fixture、固定模型响应和 replay runner。验收标准是评审者不配置 OpenRouter Key 也能复现解析、归一化、合规检查与最终 requirement matrix。
在本地解析层复用同一 JSON Schema 做独立校验；当 provider 输出不合规时，返回明确错误或受控降级，而不是仅依赖 TypeScript 类型和供应商 strict 参数。
综合评价
BidRoom Agent 的场景选择、证据优先原则、技能说明和公开核心代码均较扎实，已经具备可演示 Agent 的基本形态。下一阶段最重要的是让“五技能”主张与实际调用结构完全一致，并用自动化测试和无密钥 replay 将运行证据开放给交叉评审者。这样可以在不公开私有平台的前提下显著提高可信度。
查阅信息与限制
感谢 Yorimi 详尽的静态代码审查和具体、可操作的反馈！
▎
▎ 您指出的问题非常关键，尤其是文档描述与实际实现之间的差异，以及测试、离线复验和 Schema 校验方面的不足。针对这些问题，我们计划逐项改进：
▎
▎ 1. 明确“五项技能”的实现语义：当前实现确实是将五个阶段组织在一次 LLM 调用中完成，现有文档表述容易让人理解为五次独立调用。我们会更新 README，明确说明这是“单次调用中的五阶段结构化分析”，避免产生歧义。
▎ 2. 补充自动化测试：目前测试覆盖不足，现阶段主要依赖 tsc --noEmit。后续会增加文件边界处理、JSON 解析异常、置信度归一化以及 OpenRouter 异常等场景的单元测试，并接入 CI。
▎ 3. 提供无密钥的本地复验路径：计划提供脱敏的 tender fixture 和固定模型响应，同时增加 replay runner，使评审者无需配置外部 API Key，也可以复现核心处理流程。
▎ 4. 增加本地独立 Schema 校验：会在 analysis.ts 的解析层增加本地 JSON Schema 校验，确保即使供应商侧发生降级、修复或返回格式不一致，也能在本地发现并处理不合规结果。
▎
▎ 再次感谢这次专业且有针对性的评测。以上改进会在后续提交中逐步落实，也欢迎继续提出具体测试场景和复验建议。