Agent 不是魔法：把 AI Agent 当分布式系统来设计

Agent 是当下最热也最容易被神话的概念。剥掉包装，一个 Agent 无非是：LLM 做决策，工具做动作，循环做迭代。这套东西我们太熟悉了——它就是一台分布式系统。把分布式系统几十年的经验搬过来，Agent 的很多“玄学问题”立刻变成工程问题。

状态：Agent 的会话就是有状态服务

Agent 的上下文就是它的状态。状态外置（持久化到存储）、状态版本化（每次工具调用后记录），系统崩溃后可以恢复——这是分布式系统的基本功，Agent 同样需要。

工具调用必须幂等

工具是 Agent 的副作用接口。一次网络重试导致重复扣款、重复下单，是 Agent 应用最常见的线上事故。应对：每个工具调用带上幂等键，服务端去重；无法幂等的操作（支付、发送）一律加人工确认点。

超时与熔断要分级

LLM 调用、工具调用、整体任务，三个层级要分别设超时。工具超时 2 秒、LLM 超时 30 秒、任务级超时 5 分钟，逐级兜底，避免一个卡死拖垮整条链路。

重试要有策略

LLM 的失败有系统性（限流、超时）和偶发性之分。限流要退避重试，超时要快速失败，幻觉导致的“坏结果”不能靠重试解决——要靠评估与校验。

任务编排就是消息队列

多步任务天然是事件驱动的：每步完成产生事件，触发下一步。用任务队列 + 状态机管理，而不是让 LLM 在单次调用里“一把梭”，可恢复性和可观测性都会好一个数量级。

可观测性：一次 Agent 运行要能完整回放

Agent 的关键指标不是 token，而是：每步决策、调了哪个工具、参数是什么、结果如何、耗时多少。端到端 trace 一次运行，出问题才能定位到具体一步，而不是对着黑盒猜。

一致性：外部副作用不可回滚

传统事务可以回滚，Agent 调用外部系统的副作用不能。设计上接受“至少一次”语义，配合幂等与补偿；高影响操作永远停在人工确认点。

小结

Agent 的难点从来不在提示词，而在工程化：状态、幂等、超时、可观测性、一致性。你不需要魔法，你需要的是一份分布式系统设计清单——而这份清单，资深工程师早就有了。