PIBench：支付集成场景的 coding-agent benchmark
PIBench：支付集成场景的 coding-agent benchmark
为什么重要
PIBench（Alipay-PIBench）把 coding-agent 评测放进真实支付集成任务：9 个产品特定项目、18 个任务实例，覆盖 Basic 的功能性支付完成与 Advanced 的风险感知支付加固。它对 Agent-Benchmarks 的贡献在于：真实工程任务不只是“改代码通过测试”，还包含业务状态一致性、可靠性、安全和场景化 rubric。
对 Hermes / llm-wiki 来说，PIBench 也提供了“技能是否真正帮到 agent”的可复查实验形态：同一任务、项目、指令和环境下，对比有/无 alipay-payment-integration skill 的表现。这比单独展示 skill 文档更能说明 External-Agent-Skills-Design-Patterns 的实际价值。
机制 / 一阶原理
PIBench 的 benchmark construction 将每个支付产品绑定一个代表性项目，每个任务由目标产品、业务 workflow、初始仓库和场景化集成请求组成。评估使用场景特定 rubrics，把结构性要求、可执行要求和支付领域要求拆开，并结合确定性检查与 LLM-assisted criteria。
一阶原理是：专业领域 coding agent 的难点在“代码正确 + 业务状态正确 + 风险边界正确”的交集。普通单元测试可能证明某个函数跑通，却不能证明支付流程的幂等性、异常状态、风控加固和业务语义一致。
与现有 wiki 的关系
| PIBench 与 AssetOpsBench：工业运维场景的 agent benchmark 同属 domain-realistic benchmark：前者是支付集成，后者是工业运维。它也延续 [[coder-eval-skill-evaluation-ci | coder_eval]] 和 Agent-Benchmarks 中的 skill evaluation 方向，但把 skill 效果放到支付领域 end-to-end workflow 中测量。 |
对 Hermes / llm-wiki 的可执行启发
- 评估外部 domain skill 时，应尽量采用 paired skill study：同任务同环境比较 with-skill vs baseline，而不是只读 skill 内容。
- 对高风险业务自动化，验收标准要拆成 functional、reliability、security、business-state consistency，而不是只有“测试通过”。
- llm-wiki 可以把 domain benchmark 作为 radar 轮换主题，避免 AI 工程知识库只收通用 SWE-bench / repo repair，而忽略支付、运维、数据、客服等专业流程。
失败模式 / 边界条件
PIBench 的强项也带来边界：支付产品、SDK、业务流程高度领域化，结论未必能直接迁移到普通 Web/App coding；LLM-assisted criteria 需要保留证据，避免 judge 黑箱化。若 benchmark 任务过于贴近某家平台的文档和 skill，评估结果也可能更多反映生态熟悉度，而不是通用 agent 能力。
深度判断
评分：relevance 4/5，novelty 4/5，durability 5/5，actionability 4/5，source-quality 4/5，depth-potential 5/5。值得晋升，因为它把 coding-agent benchmark 推进到真实领域业务集成与 paired skill study；当前仅基于 README，后续可补 arXiv 技术报告。
写入记录
- 2026-08-06 09:00 CST：新增 PIBench 来源页，聚焦支付集成 benchmark、业务状态一致性和 paired skill study。