Agent Harness 深度解剖：承载 10000+ 智能体并发的 12 个核心组件很多团队做 Agent 的第一版都很像：前面挂一个聊天接口，后面接一个大模型，再补几个工具调用。单用户体验往往不差，但一旦进入客服、运营、巡检、自动化审批这些高并发场景，系统很快就会暴露出四类问题：会话状态跟着 Pod 一起消失，扩容后上下文错乱。工具调用把数据库、订单服务、搜索服务同时打满。模型成本不可控，长上下文把延迟和账单一起抬高。出现错误时只能看到一段日志，无法回答“这个 Agent 为什么这样决策”。这时团队需要的已经不是“再换一个更强的模型”，而是一套能承接大规模并发、明确状态边界、可观测且可治理的Agent Harness。它本质上是一层运行时和编排平台，负责把模型、工具、记忆、权限、任务和基础设施组织成一个能稳定运行的系统。本文不按“概念介绍”展开，而是沿着一个更贴近工程现场的问题来讲：当 Agent 并发从几十提升到上万时，原本简单的单体方案为什么会失效，平台层到底要补哪些能力，哪些组件值得自研，哪些直接复用云原生设施更划算。先说结论：不是所有团队都需要 12 个组件如果你现在只有下面这类场景，就没必要一开始搭完整 Harness：单模型、低并发、无长会话状态。工具调用只有 2 到 3 个内部 API，且都能承受同步流量。没有多租户隔离、审计和权限治理要求。允许人工介入，暂时不追求严格的链路追踪和回放。这类阶段通常一个 API 服务加 Redis 就够了。Harness 真正有价值的前提是：Agent 生命周期长，执行链路跨多次请求。工具调用很多，且下游并不总是稳定。需要多租户、灰度、限流、审计、成本归因。单次会话已经不是“问答”，而是“状态推进”。换句话说，Harness 解决的是系统性复杂度，不是“让回答更聪明”。一条请求在系统里到底怎么走先建立全局视角。一个生产级 Agent 请求，通常不是“模型返回文本”这么简单，而是下面这条链路：