Hermes A2A部署：网关超时修复不等于任务成功

wiki/ai/sources/automata-a2a-timeout-transport-versus-task-success.md

分类：ai / sources · 更新：2026-10-23 09:14

Hermes A2A部署：网关超时修复不等于任务成功

知识点轴：A2A / harness-runtime / benchmark-evaluation，关联MCP Gateway；sandbox-security体现在有限预算、凭据和副作用恢复边界。 这是第三方公开Hermes部署的10-16运维案例，不是用户实例事故，也不是今日新漏洞。读到issue/完整两条跟进、PR diff、固定HTTPRoute及后端问题更正；作者运行证据未本机重放。

为什么对用户重要

a2a-cli-client-timeouts-fallback-and-credential-scope讲的是客户端分段/idle/绝对预算。本例补上真实网关配置→Envoy数据面→长连接响应→A2A业务终态的证据链，而且最后“修复验收通过”的HTTP200里明确是 TASK_STATE_FAILED。它提醒无人cron和长程委托：网络层修复成功，仍可没有业务结果；不能看到closed issue、连接撑过60秒或有task id，就宣称agent完成了工作。^[raw/articles/automata-a2a-route-timeout-and-failed-task-primary-2026-10-23.md]

原始事件与证据等级

层次	原始记录	能证明什么，不能证明什么
发现/接入	issue称匿名Card `/.well-known/agent-card.json`返回200、name为automata；短任务约27s成功	维护者历史陈述，不是本轮获取Card；无registry、签名或跨实现conformance验证
故障	维护者称认证 `message/send`长任务3/3约60s被纯文本 `upstream request timeout`截断，后查客户端自造id找不到task	这类文本不是JSON-RPC任务失败；自造id不存在不证明服务端没有真实task/effect，亦不证明所有polling机制失效
固定修复	PR #2987只在A2A HTTPRoute rule加 `timeouts.request: 0s`；merge `4f556a142fd608b43d23b1a54f4aba373b8e9941`；backend port9900，api-server路由未改	本轮固定文件与diff可核；不是通用建议将所有网关timeout清零，也未在用户集群部署
已装配	维护者称route实际对象为0s，Envoy config_dump的timeout/idle_timeout为0s，合并后无原UT标志	作者运行回执支持修复生效；本轮没有权限查看该数据面或全部日志
传输验收	一次curl240s自行到cap、http000；另一次300.1s返回HTTP200和393字节JSON	前者仅证明未撞旧60s墙，不是任务成功；后者证明长请求返回协议对象
业务终态	上述JSON有 `TASK_STATE_FAILED`与`[agent did not reply in time]`；维护者勾选tasks/get验收	任务失败是明确结果；tasks/get勾选属于作者陈述，贴出的正文没有完整独立polling原始回包

本轮仅做匿名Card读取：经代理TLS EOF，另一次直连curl到时限未返回。因此不声称当前Card可访问，也不以本机网络失败断言该服务宕机。 没有提交认证message/send、查询他人task或执行运维操作。

一阶机制：多层时钟与排队不是一回事

原问题把60秒归因于该部署合成路由timeout；这是具体controller/集群的行为，不能写成“Gateway API统一默认60秒”。固定YAML只证明显式request设置为0s；idle配置与controller实际解释仍须数据面读回。移除这层截断后，下游时钟仍在：排队等待首chunk、stream stale watchdog、agent turn deadline、客户端总deadline、任务保留期与cron落盘余量。

后端 #2990更正了初始“llama.cpp故障”诊断：维护者观察实际处理路径是halogen-flash/uvicorn，slots饱和、队列等待可达330s，而Hermes stale-stream watchdog在180s无chunk时离开并重试；后端有迟到完成/丢弃token记录。运营者最终接受其为当时共享容量下的正常排队，不修服务器。HTTP200 headers但零chunk，与HTTP响应/业务失败、服务端真正未执行，分别留证。这些具体阈值来自那套部署，不能推断用户当前Hermes默认值或容量。^[raw/articles/automata-a2a-route-timeout-and-failed-task-primary-2026-10-23.md]

重试还可能恶化排队：若断流后旧请求没有可靠取消，新的尝试会叠加；但本例没有足够证据证明具体重复副作用。因而恢复前先用可信server task id、幂等键和独立effect回查，不能凭超时盲重发写任务。A2A-Agent2Agent-Protocol的任务生命周期、MCP-Gateway-Runtime的路由治理与Harness-Engineering的预算/取消需要协同，而不是各自加大timeout。

对 Hermes / A2A runner 的最小验收合同

分层记录，分层判成功：单次保留request/message/task/context id、实际peer URL与身份、route配置/版本、首headers/首chunk/最后事件/终态时间；分别记网络终结、协议返回、Task state及独立业务effect。HTTP200 ∧ TaskFailed不可映射success。
只修已证故障层：受控环境验证>旧超时墙的无副作用任务，先看渲染route，再查有效数据面与日志。若关request timeout，外层仍保留绝对deadline、并发/队列/资源预算和取消；不将0s推广到整站，也不假设heartbeat可绕过所有absolute timeout。
恢复不拿客户端id猜服务端状态：尽早获得并持久化服务端task id；若协议/实现支持可恢复异步任务，再测Get/Subscribe/Cancel/终态保留。能poll不代表能接管执行，轮询Task失败也不自动重发原写操作。
量化排队与业务结果：正例应明确完成业务且读回effect；负例分别覆盖route截断、首token排队超过watchdog、总deadline、cancel及同幂等键重连。记录取消是否真的抵达后端、迟到结果是否仍写副作用，不能只检查socket关闭。
凭据与URL单独验：原issue还列出另一个peer的401与HTTP/HTTPS配置漂移，和60秒截断分开记。入口通过认证不能证明任务owner隔离、下游受众或发现凭据安全，沿用hermes-a2a-live-session-security-boundaries的用户实例启用边界。

边界与未解问题

这是有固定manifest和公开运维证据的个体案例，不是企业规模部署/benchmark或所有A2A兼容性证明；没有真实registry、push、签名Card、多租户owner负例与完整trace。已闭环的是作者所定义的网关截断问题；业务成功没有由所贴300秒样本证明。本文只提出可移植的验收合同，不修改用户网关、watchdog、模型容量或peer配置。

相关：llm-wiki-optimization-2026-10-23保存候选评分；LLM-Wiki-Optimization-Log将传输/任务/业务分验并入原控制链。

写入记录

2026-10-23 09:10 CST：新增公开Hermes A2A路由修复案例，拆分配置/数据面/HTTP/Task/effect与多层超时，保留后端诊断更正、当次Card不可达和未本机E2E的证据边界。
2026-10-23 09:13 CST：补关键运维证据来源定位；本轮定向检查通过，云端语义检索相关问法实际首位召回本文。