把结论先说清楚Orkas 这轮重构本质是把 Agent 从“能跑通的 Demo”变成“能稳定扛住生产流量的执行系统”。触发点不是一次产品评审而是一场很狼狈的压测——100 路并发打进来旧平台的会话状态直接串台工具调用超时叠成雪崩内存曲线一路冲高直到 OOM。我盯着监控面板脑子里只有一个判断这不是调参数能救回来的架构假设从一开始就错了。Orkas 是我们组自研的 Agent 平台前后跑了两年接进十几个业务方、挂载上百个工具函数。到第三年的时候功能越加越密性能反而越跑越差。这次重写前后花了两个多月砍掉重写的是执行内核、记忆存储、并发调度和安全隔离保留复用的是对外 API、消息格式和 Skill 注册体系。文章按“事故→地基→记忆→并发→工具→安全→上线”的顺序把决策逻辑、技术选型和踩过的坑完整记下来。给正在做 Agent 平台或者准备从 0 到 1 搭 AI Agent 的同学应该能省不少弯路。1. 导火索一场压测事故把旧 Orkas 的底裤扒了个干净1.1 事故回放三个症状同时出现的 40 分钟这次重构的导火索是一次压测事故。事故发生在大版本上线前一夜我们用 100 路并发做压测每路用户连续发 20 轮消息模拟真实的业务咨询和工具操作。跑到第 30 分钟的时候监控面板上同时出现三个异常。第一个是上下文串台。用户 A 的对话里开始出现用户 B 的中间结果比如 A 在查订单模型的思考过程里却混进了 B 的库存数据。第二个是工具调用超时雪崩。工具执行器默认用 200 线程的线程池但单次模型推理就需要 5 到 8 秒线程池被打满后新调用全部排队排队一旦触发重试重试又进一步加剧线程池积压最后看到的现象是 80% 的请求超时失败。第三个是内存 OOM。每一轮对话都把完整历史对象留在内存没有归档策略100 并发乘以 20 轮每轮几十条消息堆直接被撑爆。这三个症状同时出现基本宣告旧架构的死刑。当时我们的处理方式当然是先扩容、降并发、临时加缓存把线上稳住但大家心里都清楚这只是把问题往后推了。1.2 追根旧架构的三个“纠缠”压测结束之后我们把代码翻了个底朝天问题集中在三层纠缠上。第一层是状态管理纠缠。旧架构用一个全局内存 Map 保存会话状态key 是“用户 ID 加自增序号”并发场景下先到的响应可能被后到的覆盖。这个方案在小流量下没有任何问题但一旦多个请求并发读写同一个 Map就完全不可控。第二层是调度执行纠缠。Agent 的“思考—行动—观察”循环和业务回调被写在同一个进程的异步回调里工具调用、模型调用、业务侧的状态更新互相嵌套。代码层的表现是一个方法动辄几百行里面同时管 session、管 LLM client、管 tool executor。第三层是失败处理纠缠。没有背压机制没有排队上限超时后无限重试重试失败又不知道自己失败了几次。我们根本不知道“系统现在到底在忙什么”只知道它在忙。这三层纠缠的本质是把 Agent 当成一个长连接的异步 RPC 服务来设计。但 Agent 真正的运行模型是一个有边界的自治执行体它在不断循环、不断产生副作用、不断读写自己的记忆。这个假设错了后面所有补丁都会打在错误的抽象上。1.3 为什么推倒重写而不是继续打补丁处理事故的时候团队内部也讨论过要不要接着打补丁。补丁方案有两个一个是给全局 Map 加分布式锁一个是把线程池换成协程并加大超时阈值。我没有同意。理由很简单如果修一个问题要同时改动调用方、存储层和执行器三处而且改完之后大概率还会在下一个压力峰值暴露同类问题那就不是修是给自己埋雷。我给团队定的判断标准是修复涉及的核心抽象已经错了且无法通过局部改造纠正就重写。但重写不等于推翻一切。我们从一开始就划了一条红线对外 API、消息格式和工具注册协议必须保持兼容业务方不能感知到平台在换心脏。事实证明这条红线非常重要它让整个重构过程可以做到灰度替换而不是午夜停机大迁移。2. 重构的第一块地基执行引擎与编排层的彻底分离2.1 Agent 执行循环不是什么玄学就是一个状态机重写的第一步是把 Agent 的执行过程还原成它的本来面目。不管底层用 ReAct、Plan-and-Execute 还是其他编排范式抽象到最底层都逃不开一个循环感知输入、规划下一步、调用工具、观察结果、再规划、直到产出最终回复。这个循环可以用状态机建模。我们把状态定义为 idle、planning、tool_pending、observing、producing、done 六个状态。核心的驱动逻辑是事件循环收到用户消息进入 planning发起工具调用后进入 tool_pending等工具事件回来进入 observing然后回到 planning 或者进入 producing最后结束于 done。用伪代码描述一下这个内核的形状from enum import Enum class AgentState(str, Enum): IDLE idle PLANNING planning TOOL_PENDING tool_pending OBSERVING observing PRODUCING producing DONE done class RuntimeKernel: def __init__(self, strategy): self.state AgentState.IDLE self.strategy strategy # 编排策略只负责决策 async def dispatch(self, event): if event.type user_message: await self._on_user_message(event) elif event.type tool_result: await self._on_tool_result(event) elif event.type timeout: await self._on_timeout(event) # 每个事件处理完把状态快照写入存储 snapshot(self)这个内核不关心你用的是哪个大模型、工具列表有多长它只负责一件事让状态在事件驱动下正确流转。工具调用是外部 IO等待工具返回的几秒钟里事件循环可以继续处理其他会话的事件。这样一来我们不再为每个 Agent 起一个线程而是让大量 Agent 共享同一个事件循环各自的上下文收敛到自己的状态快照里。2.2 编排层改成声明式策略业务方不再写胶水代码内核里面还有一个东西叫 strategy这就是编排层。重构之前每个业务方接入 Orkas 都要写一堆胶水代码自己维护模型请求、自己拼工具调用、自己处理异常。重构之后编排层全部收敛成策略接口业务方只要配置几项声明式参数。比如一个简单的客服 Agent 配置大概长这样agent: name: order_service model: provider: internal-llm name: qwen-plus temperature: 0.3 planning: max_steps: 8 terminal_condition: user_questions_answered tools: skills: [order_query, refund_check, logistics_trace] select_strategy: semantic_rank_top3 memory: short_term_rounds: 10 working_memory_ttl: 600 long_term_namespace: order_service这段配置的意思是这个 Agent 最多循环 8 步每一步最多从三个 Skill 里做语义选择模型参数和记忆策略都外置。业务方想调整行为改配置比改代码安全因为我们可以在配置层做校验和灰度而不是在代码堆里做分支。2.3 分离之后收益立刻体现在三个地方执行内核和编排层分离是我在这轮重构里觉得最值的一刀。收益有三点看得见。第一并发能力收口了。所有会话共享同一个事件循环并发控制、限流、超时、重试都被吸收到内核层处理上层业务完全不需要感知。旧架构里每个业务方自己实现的并发逻辑全部删除这直接砍掉了一批隐蔽的 bug。第二测试变得可能。内核可以脱离完整服务做单元测试我们给每个状态转移都写了用例planning 之后必须进入 tool_pending工具超时之后必须进入降级分支。重构前这种测试根本写不出来因为状态分散在各段业务回调里。第三线上排障的可解释性上来了。每个事件都有类型和 trace_id状态快照可以随时回放。之前查问题靠翻日志猜现在相当于把 Agent 的执行过程变成了一盘可以倒带的录像带。3. 记忆系统重写Working Memory 的工程化落地3.1 旧记忆方案的问题靠 prompt 硬撑永远撑不住旧版本的记忆方案简单粗暴每轮对话把全量历史往 prompt 里塞。这个方案在 10 轮以内能用但往上走就撑不住了。第一是成本问题token 消耗随轮数线性上涨一个 50 轮的长会话光是历史上下文就能吃掉几万 token第二是质量问题模型注意力被大量无关历史稀释经常出现“忘了重点”第三是窗口问题一旦上下文超过模型窗口就丢信息丢了之后模型还继续回答。但当时最让我难受的还不是这三个而是工作记忆没有独立存在。一个任务执行到一半产生的中间结果比如“刚才查过库存A 仓库缺货判断是补货还是转仓”这种信息应该放进结构化的临时存储里而不是混在对话历史里。混在 prompt 里模型一旦在某一轮没有把关键信息写回上下文这个任务就断了。3.2 三层记忆架构与各自的存储选型重写之后我们按生命周期把记忆拆成三层短期缓冲、工作记忆区、长期记忆。三层职责不同存储选型也不一样。记忆层级生命周期存储介质读取方式短期缓冲当前会话内Redis 或内存队列最近 N 轮原文直接注入工作记忆区单任务执行期内存 持久化快照结构化 KV 读取带 TTL长期记忆跨会话向量库 关系表语义检索按需召回短期缓冲负责对话连贯不需要复杂检索直接存最近 N 轮原文代价可控。工作记忆区是这次重构的重点它把任务执行中的临时变量、中间结论、已失败重试次数单独管理。每个工作记忆条目有命名空间和 TTL任务结束就清空避免下一轮任务读到上一轮残留的脏数据。长期记忆则走语义检索存用户画像、历史偏好和领域知识只有在计划阶段需要参考时才召回不无脑注入。这个三层结构落地后最直观的效果是单轮问答的 token 消耗平均下降了 45%。更重要的变化是Agent 在长任务里不再“断片”因为关键的中间状态永远可以在工作记忆区里找到。3.3 并发下的记忆一致性会话锁 版本快照记忆系统设计里最容易踩的坑是并发一致性。我们遇到过很诡异的线上问题同一个会话在某个瞬间有两个执行副本在跑一个副本在等待模型返回另一个副本因为上层重试被再次拉起两个副本同时写记忆后写的把先写的覆盖了。这类问题的根源是“同一个会话被并发执行”。解法是两条规则一起上。第一会话锁。每个 session_id 在执行期间持有一把分布式锁锁的 TTL 覆盖整个 Agent 执行循环。任何时刻同一个会话只能有一个活跃执行体其他请求进来要么等待锁释放要么直接拒绝。不同会话之间完全无锁、完全并行。第二版本快照。每次状态变更都生成一个不可变快照快照带版本号写入时按版本号做乐观锁校验。读记忆的时候永远基于某个确定的快照而不是读“最新的内存态”这样即使有短暂的副本冲突也能保证读到的是一致的数据。这两条规则实现起来并不复杂但非常关键。它们把记忆系统从“一个共享的可变内存”变成了“一串可回放的状态版本”这也是后面做可观测性和事故回溯的基础。4. 并发与性能让 Agent 扛住高并发的三道闸门4.1 为什么 Agent 这么难扛并发LLM 调用的性能特征每次聊到 Agent 并发总有人问怎么优化。我的回答是先理解模型调用的性能特征再谈优化。大模型推理是典型的 IO 密集型长尾操作。一次调用从发出到返回1 秒是最短路径5 到 10 秒很常见但在这个等待过程中CPU 基本是空闲的占用资源的是连接、线程、等待队列。传统的线程池模型在这里特别吃亏每个 Agent 会话如果占一个线程100 个会话就把线程池打满了而 99% 的线程都在 sleep 等 IO。所以 Agent 平台做并发核心不是把线程数调大而是减少“占着资源等 IO”的场景。事件驱动模型天然适配这个特征请求进来后状态机注册回调然后立刻把执行权交回事件循环等待结果返回时再恢复状态。用几百个协程就可以支撑数千个 Agent 实例在途执行。4.2 三道闸门有界并发、队列背压、超时熔断理解特征之后我们在内核里加了三个控制点叫“三道闸门”。第一道是有界并发。入口处用一个信号量限制同时在途的 Agent 执行实例数。并发上限不是拍脑袋定的有一个简单公式可以参考并发上限 ≈ 模型服务 QPS × 单个 Agent 每轮平均模型调用次数 × 安全系数举个例子模型服务 QPS 是 60每个 Agent 一轮平均要调 3 次模型安全系数取 0.7那么并发上限大约是 60 × 3 × 0.7 ≈ 126。超过这个数值模型服务就会成为瓶颈。import asyncio semaphore asyncio.Semaphore(126) async def run_agent(session_id, message): async with semaphore: await execute_agent_loop(session_id, message)第二道是队列背压。并发上限之外我们给入口配了一个有界队列超出队列深度的请求直接返回 429绝不无限堆积。队列深度也不是越大越好它只起到平滑瞬时尖峰的作用默认按“预估峰值 QPS × 平均执行时长 × 0.3”配置。第三道是超时熔断。模型调用和工具调用分别有超时上限超过就进入降级分支——比如抽一个更小的模型重试一次或者直接告诉用户当前忙不过来。同时每个 Skill 连续错误超过阈值熔断器打开 10 秒这 10 秒内不再调用该 Skill避免雪崩。4.3 压测数据与参数调优思路三道闸门上线后我们用同一套压测脚本重新跑了一遍。旧架构 100 并发下 p95 是 28 秒错误率接近 12%还出现了两次 OOM。新架构在 200 并发下 p95 是 6.5 秒错误率 0.4%全程没有 OOM。这个对比足够说明问题。参数调优的思路也想分享一下。别指望一上来参数就是对的先观察再调。压测时分批加压5 秒升一次并发看 p95 和错误率曲线的拐点。拐点出现的位置就是模型服务的真实水位再用这个水位反推有界并发和队列深度的参数。我们每次调参都会保留一次完整的压测报告作为基线后续任何代码改动都要先过基线不然优化很容易互相抵消。5. Skill 与工具调用的收敛从脚本堆到契约体系5.1 工具爆炸是必然先收敛成 Skill再谈管理Orkas 跑了两年的历史包袱里最重的一个是工具爆炸。最多的时候平台里挂了 80 多个工具函数覆盖查订单、改地址、发通知、查天气、OCR 识别、汇率换算……每个业务方都在往平台里塞自己的函数函数之间职责重叠参数风格五花八门。工具变多的直接后果是模型选不准。模型面对几百个 function 时选择准确率明显下降经常把订单查询和物流跟踪搞混或者按错误的参数格式发起调用。后来我们做了一个关键转折不再向模型暴露裸工具而是暴露 Skill。一个 Skill 是一个领域能力的封装内部可以包含多个工具函数和一套默认决策逻辑对外只呈现统一的 name、description、input_schema。模型看到的永远是一组高度抽象的 Skill而不是几百个裸函数。工具调度从“模型在函数列表里翻”变成“模型在 Skill 列表里选Skill 内部再决定怎么调”。这个改动让工具选择的准确率在三个星期里从 71% 提到了 88%。5.2 Skill 的契约体系schema、幂等性、故障演练Skill 不是简单的包装它必须有自己的契约体系。我们在注册中心里给每个 Skill 定义了完整元数据名称、描述、输入输出 schema、依赖哪些底层工具、版本号、安全等级、幂等属性。Skill 元数据必填说明name是全局唯一语义清晰description是给模型看的文案直接影响选择准确率input_schema是JSON Schema执行前强制校验handler是实际执行函数必须幂等或无副作用标注version是语义化版本变更必须升级security_level是read / write / high_risk 三档每个 Skill 上线前都要过三个测试。第一个是 schema 校验测试非法入参必须在执行前被拦截而不是在 handler 里炸。第二个是幂等性检查标为幂等的 Skill 必须保证重复调用结果一致标为非幂等的 Skill 必须在文档里明确警告。第三个是故障演练模拟底层工具超时或返回错误看 Skill 是否正确降级而不是把异常抛回给模型。这套契约体系看起来多花了几天时间但在重构期救了我们很多次。因为内核重写期间我们经常会发现某个 Skill 依赖的内部函数签名变了契约测试能第一时间报警而不是等线上用户来告诉我们。5.3 工具调用的重试、降级与成本控制工具调用的工程细节比大部分文章写的要啰嗦得多。先看重试。原则很简单只允许幂等 Skill 自动重试非幂等 Skill发邮件、下单、转账绝不自动重试触发人工确认流程。为什么自动重试一个非幂等操作最坏结果是重复下单、重复扣款这个代价模型不会替你承担。再看降级。每个 Skill 内部建议实现至少一档降级路径。比如订单查询挂了先试备用数据源备用也挂了就明确告知模型查不到该放弃就放弃不要反复纠缠同一个失败。模型反复调用一个失败的 Skill 是很常见的事降级策略要告诉它“不要撞墙”。最后是成本控制。工具调用结果也是要进入上下文的结果太长会吃掉大量 token。我们给每个 Skill 的返回加了一个“摘要上限”默认只保留前 500 个字符关键字段可以精简提取。这个细节在一个高频工具上每个月能省三到四成 token 成本。6. 安全与隔离重构里最容易欠的债6.1 Agent 的安全风险清单不止提示词注入聊 Agent 安全很多人第一反应是提示词注入外部内容里藏一段指令诱导 Agent 执行危险操作。这个确实存在但不是全部。我列一下重构时认真梳理的风险清单一共四类。一类是提示词注入来自用户输入或外部抓取内容。二类是记忆投毒恶意内容污染了长期记忆导致 Agent 后续所有行为都被带偏这种比单次注入更隐蔽、更难查。三类是工具滥用模型在权限边界不清的情况下调用了高权限工具比如一个只读客服机器人把删除接口执行了。四类是数据泄露Agent 读取了不该读的会话数据一旦发生信任就没了。6.2 会话隔离、工具分级与沙盒执行安全设计的第一层是隔离。每个会话有独立的工作区包含自己的记忆、临时文件和沙盒密钥无法访问其他会话的资源。实现上我们用“会话密钥 命名空间”双保险哪怕代码里出现跨会话读取的 bug也会在密钥校验那一层被拦下来。第二层是工具权限分级。所有 Skill 分 read、write、high_risk 三档。read 级可以直接执行write 级需要校验来源是否可信high_risk 级在执行业务动作之前必须经过用户二次确认。比如查询天气是 read直接放行发送营销短信是 write需要确认转账、删除、批量外发是 high_risk必须二次确认加管理员审计。第三层是沙盒执行。对外部副作用默认禁止比如网络请求、文件写入、进程执行一律要走白名单。Docker 容器隔离是标准做法容器里没有宿主机挂载、没有外部网络权限只有白名单服务可以访问。这一步不能省Agent 一旦被提示词注入诱导发起恶意请求沙盒就是最后一道物理屏障。6.3 借鉴“记忆防御”思路来源可信度与行为审计记忆投毒是我在重构里特别想防住的一类攻击我们发现它比提示词注入更危险一次注入只影响一轮而一次成功的记忆投毒会影响之后所有会话。参考最近业界和学术圈都在讨论的那类“主动防御记忆投毒”的思路我们在记忆写入路径上加了两道检查。第一道是来源可信度。所有进入长期记忆的内容都必须带上来源标签用户主动声明、工具返回数据、模型推理结论、外部抓取内容。来源可信度低的内容不直接写入长期记忆而是进入一个“待核验区”等模型在后续轮次中通过高可信来源验证后再转正。第二道是全链路行为审计。每次模型调用、工具调用、记忆读写都带同一个 trace_id落盘到审计日志。审计不是事后翻黑盒而是提供完整的执行回放。我们曾经靠这段回放定位过一次可疑操作一个 Agent 在某轮读了外部文章后下一轮就尝试调用 write 级工具虽然被权限拦住但审计日志让我们发现了注入路径并封掉了那个来源。提示Agent 安全不能靠上线前加一个防火墙解决。它必须嵌入状态机的每个读写点从隔离、授权、沙盒到审计缺一环都可能在最糟糕的时候出问题。7. 上线与复盘灰度、测试、可观测性7.1 回归测试先写剧本再改代码重构初期我们吃过一个亏代码改了三分之一想验证行为没变结果只能靠人肉点页面。效率低不说还容易漏。后来我强制团队做了一件事从真实业务场景里抽象出 300 多个“剧本”覆盖订单查询、物流跟踪、退换货、多轮追问、工具失败、风险内容拒绝等场景。每个剧本有固定输入、预期行为关键词和结果断言。这套剧本集成了重构的护栏。每次内核有改动先跑剧本集比对输出有没有漂移。没有剧本的 Agent 重构等于蒙眼开车——你以为只是优化了性能实际上可能已经把某个业务场景的行为改歪了。7.2 灰度节奏与关键指标重写后的 Orkas 上线不建议一把梭。我们的顺序是内部 10% 流量先跑一周然后外部 5%、20%、50%、100%每一步停留至少 24 小时。灰度期间盯五个指标请求成功率、p95 延迟、上下文串台率、工具失败率、安全事件数。其中“上下文串台率”是这次重构的特有监控我们自己定义了一个指标专门统计会话里出现非本会话内容的次数。任何指标劣化超过 5%立即回滚。所以整个灰度过程必须保留旧版本并行运行直到新版本稳定超过两周再摘。7.3 复盘中最遗憾的两件事现在回过头看重构里最让我后悔的是没有一开始就做事件溯源。所有状态变更如果能从第一天就落成事件日志排查问题的速度会快得多。但当时为了赶进度我们只做了状态快照没有做事件流后来补的时候发现历史数据格式已经变了迁移成本直接翻了一倍。第二件后悔的事是剧本集建得太晚。如果先花一周把行为剧本写好再动第一行代码重构前三周我们就不用天天人肉验证了。这个教训写在这里给所有准备重写 Agent 底层的人测试剧本不是测试阶段的事它是重构动工之前就该有的地基。最后再分享一个个人体会Agent 平台的底层重构真正难的不是某个技术点而是你能不能在重写的时候始终守住那些用户已经依赖的行为边界。技术债可以还信任债还不起。