企业官网建设流程全解析

高可用架构选型别只比较参数

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 与状态接口访问框架，第三方实现放在适配层；选一个真实流程做迁移演练，才知道存储、类型和观测需要改哪里。每个工具的重试、权限与并发应可配置，任务步骤、模型调用和人工接管也应被记录。功能再多，若故障会形成无界循环或业务被框架锁住，就不适合承担高可用目标。