高可用架构选型别只比较参数Agent 工作流的架构选型吞吐、插件数量和社区热度只能作为筛选条件。真正影响可用性的是模型输出不合法、工具变慢、节点重启或框架升级时任务能否停在可解释的位置。一个演示能跑通只说明顺利路径存在上线前还要看失败会不会扩散、状态能不能恢复以及今后替换框架要付出什么代价。用自己的故障样例做比较先准备一组贴近业务的任务参数缺失、无效 JSON、工具超时、重复请求、节点中断、恢复后继续执行。候选方案应在相同模型、工具和资源条件下运行记录每一步状态、重试原因和最终结果。通用 Benchmark 可以参考却不能替代这些路径。比较时我会重点问三件事。任务状态只在内存里还是能在明确检查点持久化恢复后如何避免重复执行已经产生副作用的动作解析失败与工具失败是否有不同的重试预算连续相同错误能否停止最后业务工具、消息类型和状态模型是否被第三方类型绑死升级或迁移时是否有适配层可依赖。无效参数不能靠猜测修好自动补逗号或删除字符看似能省一次模型调用实则把“模型输出无效”变成了系统对用户意图的猜测。读操作尚需谨慎涉及发送消息、删除数据或资金动作时更不应静默修复。合理流程是严格解析、按工具 Schema 校验向模型返回有限且结构化的错误超过预算就结束并要求用户确认。工具也需要各自的超时、并发和权限。数据库查询、外部 API 与发送类动作的容量和风险不同不能放进一个无界工作池。框架是否暴露这些控制点往往比内置工具数量更值得评估。func (e *Engine) Execute(ctx context.Context, name string, raw json.RawMessage) (string, error) { tool, ok : e.tools[name] if !ok { return , errors.New(tool not registered) } if !json.Valid(raw) { return , errors.New(invalid json) } if err : tool.Validate(raw); err ! nil { return , err } callCtx, cancel : context.WithTimeout(ctx, tool.Timeout) defer cancel() reply : make(chan result, 1) go func() { value, err : tool.Run(callCtx, raw); reply - result{value, err} }() select { case r : -reply: return r.value, r.err case -callCtx.Done(): return , callCtx.Err() } }这段代码只隔离了一次调用并没有自动解决持久化、幂等或资源泄漏。若Run忽略 Context外层超时后它仍会继续运行写操作还要在工具内部建立授权、审计和幂等边界。把限制写在接口上比寄望执行器“聪明地处理一切”可靠。还应检查观测是否足够一次任务用了哪个工具、何时重试、消耗了多少预算、在哪个检查点保存状态都要能回查。恢复流程尤其要区分“尚未开始”“已经成功但响应丢失”和“执行结果未知”它们不能使用同一条重试规则。把这些状态写进测试才不会在节点重启时靠人工猜测。把退出成本也写进结论选型结果应包含不采用什么以及如何退出。让业务通过项目定义的 Tool 与状态接口访问框架第三方实现放在适配层选一个真实流程做迁移演练才知道存储、类型和观测需要改哪里。每个工具的重试、权限与并发应可配置任务步骤、模型调用和人工接管也应被记录。功能再多若故障会形成无界循环或业务被框架锁住就不适合承担高可用目标。