Pega A2A实践：Card路径、执行到达与界面交付的证据链
Pega A2A实践：Card路径、执行到达与界面交付的证据链
结论与用户价值
知识点轴：A2A / harness-runtime / benchmark-evaluation；关联 MCP Gateway / sandbox-security 的逐跳身份边界。 一个社区开发POC与两个配置/故障线程提供了比“支持A2A”更可迁移的经验：Card与健康GET成功、实际POST到达、响应契约被消费、用户得到完整交付是不同关卡。 它能改进Hermes外部agent验收及“执行成功但结果为空”的排查，联读 A2A-Agent2Agent-Protocol、Agent-Benchmarks、MCP-Gateway-Runtime。
时间分别是2026-10-08、03-06起与07-17，属于今日新入库而非今日新发布。来源是Pega社区作者自述，不是本机部署证明；POC明确不覆盖生产安全、企业认证、复杂异步或规模化观测。正文可读，截图只保留原链接，未审图/视频，也未获得真实live Card或调用服务。
案例结构：委托边界可以由普通业务服务实现
10月POC使用两项外部Python/Flask能力：Credit Assessment与Fraud Assessment，经ngrok开发HTTPS入口，分别由Pega specialist连接，再由orchestrator按请求调度一项或两项。业务逻辑故意简单，不要求每个外部服务内部都有LLM。
价值在职责分离：orchestrator负责选择/聚合，specialist持Pega侧能力入口，外部服务封装独立实现。多层agent名称并不自动意味着智能推理、持久task、安全委托或企业部署。 不能把架构图的层数当interoperability证据；应抓每个真实caller→peer调用及其结果关联。
机制一：版本、Card位置和执行URL分别核验
POC给出GET /.well-known/agent.json，Card示例protocolVersion: "0.2.5"、streaming:false、pushNotifications:false、skill输入/输出text/plain与公开url；作者强调这些值取决于自己的POC环境。它是可读Card示例，不是本轮从live peer取到的Card，也不是最新A2A规范模板。
7月故障线程中，作者称Pega Infinity 25.1.3/26.1连接Google ADK：外部工具能调JSON-RPC，Cloud Run可见GET，但Pega报Service URL was not provided，没有所需POST；随后自报将Card link改为/.well-known/agent-card.json解决。3月配置帖又使用旧路径。保留各自时间/环境，不静默统一成“Pega永远必须用某一路径”，也不直接判旧示例无效。
第一性解释是：connector需要发现文档位置→解析该版本Card→提取正确execution endpoint/binding→真正dispatch。独立HTTP客户端能调POST仅证明服务端那条路径可用，不证明Pega解析/认证/传输相同。跨版本具体解析行为仍需固定产品文档或真实抓包，本轮未获得。
机制二：执行返回与被消费、被交付分开
POC作者记录：HTTP200仍可能Pega不显示；Python返回JSON但结构不符仍不渲染；Pega报执行成功而UI为空。排查要至少分：
| 证据关卡 | 能证明什么 | 不能替代什么 |
| Card GET与健康GET | 发现/基础可达 | RPC POST确实发生 |
| inspector中实际POST | 请求到达指定peer | 业务成功或正确响应schema |
| 原始response与解析产物 | 协议数据可消费 | 正确关联到用户/原任务 |
| 编排层聚合结果 | 收到并合并子结果 | 用户UI/附件/业务端真实交付 |
| 用户可见结果与业务effect | 对应交付/状态 | 全局安全、幂等、跨owner正确 |
作者用ngrok inspector比对请求/回包；trial环境里Application Agent的AI tracer可用，Case Type级则查Pega-Autopilot-Conversation记录。后者是作者调试方式，不保证所有版本同类存储、不把“猜测tracer也读此记录”写成实现事实。用户日常排查应以事件时间、call ID/Task ID和原始回包逐条关联，不能拿当前latest状态补历史链。
机制三：发现认证、执行认证和业务主体不同
配置帖为Card discovery和execution分别指定authentication profile，可通过application setting切dev/test/prod；它们可以相同，也可不同。8月回复建议从Access Group context改Operator ID解决某人的OAuth问题，只是具体环境建议，不应无脑推广为通用安全配置。
与 cognigy-a2a-discovery-tool-filter-and-task-contract 的发现凭据/实际调用、sap-a2a-bridge-principal-resource-and-task-boundaries 的service/user/resource分验一致：拿到token或发现Card不证明execution token audience、终端用户授权或Task owner成立。此POC没有企业auth演示，不能声称已验证凭据隔离；ngrok公开开发入口也不宜直接变生产方案。
对Hermes与内部互通评测的启发
- 把Card URL、实际协议/binding、advertised execution URL、当前host/版本单列；路径变更只按实际兼容合同处理，不自动fallback并把凭据发送到新origin。
- 用同一关联ID逐跳保存GET、POST、原response、parse结果、Task/业务状态与用户交付；无POST先查发现/解析/本地授权，不先归咎模型“没能力”。
- 加入“服务可直调但connector不POST”“HTTP200但无协议产物”“成功状态但空UI/缺附件”负例；合法路径必须完成，拒绝/timeout与业务effect独立记账。
- 真正企业验收另补双owner、撤销、无凭据/错误audience、重试/取消及副作用零重放；支持声明和社区截图均不替代这些负例。
证据边界与深度判断
晋升原因是三篇互相补充的具体Card示例、分阶段认证配置、带产品版本的失败与作者修复、以及200/解析/UI不一致的真实自述；可形成可复用诊断合同，不只是单工具介绍。仍只有社区案例证据、部分代码在图片中，不能宣称完整可运行实现、TCK、任务生命周期/stream/push或企业部署已验证。
尝试官方registering-external-agent.html返回HTTP200，但抽到的仅站点导航shell，未得到正文；它只留作抓取边界，不用于给社区路径/认证结论背书。未部署Flask/ngrok/Pega、未联系外部端点、未处理真实贷款信息或生产凭据。
写入记录
- 2026-11-02 09:11 CST：新增Pega社区POC/配置/故障三层证据，保留旧新Card路径的版本适用范围；补逐跳GET/POST/解析/交付与双认证验收，明确截图/官方shell及无本机部署边界。