从一条 SRE 的论断说起

TikTok 的 SRE 技术负责人近期抛出一个观点：AI Agents 说到底就是分布式系统。乍听像是工程老兵的比喻，细想后会发现，这并非修辞，而是一个精准的抽象。

一个 Agent 运行时，要调用 LLM、检索知识库、操作外部工具、处理异步回调、维护会话状态——这些组件分布在不同的进程、机器甚至云区域。它们通过消息传递协作，面临超时、重试、部分失败、数据一致性等问题。这与典型的微服务系统几乎没有本质区别。

Agent 即分布式系统：一个映射练习

用分布式系统的词汇重新描述 Agent 链路：

Agent 的每一次思考-行动-观察循环，本质上就是一个分布式事务的尝试。工具调用可能失败，LLM 可能超时，上下文可能因网络分区而不一致。这些都不是 AI 独有的问题，而是分布式系统领域的老朋友。

关键洞察：Agent 的智能并不存在于单个 LLM 调用中，而是存在于多个组件之间的协调与状态流转中。因此，Agent 的可靠性问题，本质上是分布式系统的可靠性问题。

控制平面与数据平面：理解 Agent 架构的钥匙

网络领域有个经典划分——控制平面与数据平面。路由器中，控制平面负责计算路由表（决策），数据平面负责按表转发报文（执行）。这个思想正被 Agent 工程化领域重新发明。

所谓 "薄 Agent Loop，厚 Control Plane"，正是对这一思想的呼应。Agent Loop 是数据平面：执行具体动作——调用工具、读取上下文、生成回复。Control Plane 是决策层：决定下一步调用哪个工具、何时终止循环、如何切换策略。

传统 Harness 的问题在于把大量控制逻辑塞进 Loop 本身，循环体越来越胖，职责混乱：既要管理状态，又要做策略决策，还要处理错误恢复。好比把路由计算和报文转发写进同一进程，最终难以维护和观测。

更合理的架构是：让 Agent Loop 保持轻薄，只负责执行和反馈；把策略、路由、容错、状态管理上移到独立控制平面。TiDB 团队用数据库思维重做 Harness 时，正是把 Agent 状态当作数据库事务来管理——提交、回滚、重放，这些经典机制成了控制平面的核心能力。

异步与并发：从 Kiro Crew 看 Agent 协作

AWS 开源的 Kiro Crew 提供了一个具体视角。它让 Coding Agent "异步跑起来"，意味着 Agent 不再是同步阻塞的请求-响应循环，而是可并发调度、按需唤醒的任务系统。

这与异步分布式架构的演进路径如出一辙：从同步 RPC 到消息队列，从单体调度到分布式任务编排。Kiro Crew 的每个 Agent 本质上是可独立运行的工作单元，通过事件或消息协作，而非共享内存或同步调用。

这种设计带来两个关键收益。第一，资源利用率提升：Agent 等待 LLM 响应时可释放计算资源。第二，容错性增强：某个 Agent 的失败不会拖垮整个工作流，可通过重试或补偿恢复。

但异步化也引入了分布式系统中最棘手的两个问题：部分失败与重复执行。Agent A 调用 Agent B 但响应超时——B 到底执行了没有？重试会不会造成重复提交？这正是分布式事务中 "Exactly-once" 语义的翻版。Kiro Crew 等框架的价值，正是在框架层面提供这些保证。

安全与凭据：Agent 时代的访问控制难题

当 Agent 成为分布式系统，安全问题也变得分布式化。GCP 推广的 Workload Identity Federation，本质上在解决 Agent 的 "服务身份" 问题——让工作负载不再依赖长期有效的静态凭据，而是通过短期、自动轮换的令牌证明身份。

这对 Agent 系统尤为重要。一个 Agent 运行时可能访问多个云服务和内部 API，若每个集成点都配置长期密钥，攻击面将急剧扩大。短期令牌机制缩小了攻击窗口，也简化了密钥轮换的运维负担。

更深一层，Agent 的权限模型应遵循 最小权限原则：每个任务只获得完成所需的最小权限集。这要求控制平面具备细粒度授权能力，能根据任务上下文动态发放凭据。这与 Service Mesh 的零信任模型一脉相承——不信任网络内部，只信任经过验证的身份。

控制平面的未来：Agent 基础设施的收敛

把上述线索拼在一起，会看到一个清晰趋势：Agent 正在从 "模型调用脚本" 演变为 "受控的分布式系统"。这个演进路径与互联网基础设施的演进惊人相似：

• 早期：单体应用（单个 Prompt 完成所有事）
• 中期：微服务化（多个 Agent 通过 API 协作）
• 现在：服务网格 / 控制平面（统一治理、观测、安全）

Cloudflare 扩展 AI 搜索、HCP Terraform 定位为 AI 驱动基础设施的控制平面，都指向同一方向：Agent 需要基础设施级支撑。就像微服务需要 Kubernetes 和 Service Mesh，Agent 系统需要自己的控制平面来管理生命周期、配置、安全策略和可观测性。

对开发者而言，新技能栈正在形成。理解分布式系统的经典理论——一致性、容错、幂等、状态管理——将成为构建可靠 Agent 的前提。只把 Agent 当作 "更好的 API 调用" 的团队，很快会在生产环境遇到墙：超时、乱序、状态丢失、重复执行——这些问题没有 AI 魔法可以解决，只有扎实的系统设计可以。

延伸思考：当 Agent 数量从个位数增长到千级别，你是否需要一个 "Agent 的 Kubernetes"？这个平台应具备怎样的调度能力和故障域模型？这或许是下一个基础设施赛道的机会所在。