引言：当AI不再是插件，而是骨架
2026年3月31日，Anthropic的Claude Code整个源代码——1900多个TypeScript文件、51万行——通过npm包里一个忘记排除的.map文件，被官方给开源了。
Claude Code负责人Boris Cherny给出的定性是：“plain developer error（普通的开发失误）”。
而Boris自己在另一个场合说过一句话：他对Claude Code 100%的贡献，都是Claude Code自己写的。
也就是说，世界上最先进的AI公司，用自己最先进的AI写自己的产品代码，依然在一个「理应有人复核」的环节上栽了跟头。
这不是AI不靠谱的故事。这是系统架构需要重新思考的故事。
01 从三层架构到三层智能架构
传统软件架构的演进路径我们都很熟悉：
- 单体架构 → 分层架构 → 微服务架构 → 云原生架构
每一轮演变的驱动力，都是同一个：系统复杂度的增长超出了现有结构的承载能力。
AI时代，这个驱动力没有变，但复杂度的来源变了。以前复杂度来自业务规模和团队规模，现在它还来自AI的不确定性。
一个能写代码的AI，可能写出完美的代码，也可能悄悄删掉一行关键配置。一个能查数据库的AI，可能精准检索，也可能误删生产数据。一个能调外网的AI，可能获取有用信息，也可能把敏感数据发出去。
所以AI时代的系统架构，正在形成一种新的三层结构：
| 层级 | 传统架构 | AI时代架构 |
|---|---|---|
| 决策层 | 业务逻辑/规则引擎 | Orchestrator + Planner Agent |
| 执行层 | 服务/微服务 | Worker Agent + Tool Registry |
| 基础设施层 | 数据库/消息队列/缓存 | 记忆系统 + 状态持久化 + 可观测性 |
这不是简单的"把微服务换成Agent"。每一层的设计原则都发生了根本变化。
02 决策层：从规则引擎到Orchestrator
传统架构中，决策由代码逻辑驱动：if-else、状态机、规则引擎。逻辑是确定性的，输入相同，输出必然相同。
AI系统中，决策由模型驱动。模型是概率性的，同样的输入可能产生不同的输出。这就带来了一个根本问题：谁来做最终决定？
很多团队的写法是让Planner Agent自己决定调用哪个Agent、是否继续、是否重试、是否结束。短期看很灵活，长期看很危险。因为大模型本质上不是一个可靠的调度器——它没有天然的成本意识、并发意识、权限意识、全局一致性意识。
生产级原则只有一句话：
Agent负责局部智能，Harness负责全局控制。
具体来说，Orchestrator必须独占五项决策权：
- 任务生命周期：每个任务从创建、规划、执行、审查、完成、失败，都要有明确的状态机
- 执行计划裁决：计划可以来自Planner Agent，但一旦生成，必须由Orchestrator接管
- Agent路由：不是每个Agent都能处理每个任务，路由要结合任务类型、Agent能力、权限、历史质量评分
- 失败处理：某个Agent失败后是重试、降级、跳过还是终止？这绝不能让出错Agent自己说了算
- 硬终止条件：必须有max_steps、max_tokens、max_duration、max_tool_calls四道硬闸
还有一个工程师容易忽略的细节：Planner应该输出"声明式计划"，而不是"命令式调用"。
声明式：{step: 1, intent: "research", agent: "researcher", input: "..."}
命令式：直接await researcher.run("...")
声明式的好处是Harness可以介入：可以重排顺序、可以并行优化、可以拒绝某些步骤、可以在执行前做安全审查。命令式则相当于把方向盘交给了Agent。
别让Agent开车，让Agent当导航。
03 执行层：从微服务到Agent + Tool Registry
微服务架构中，服务之间通过API通信，有明确的接口契约、版本管理、熔断机制。
Agent系统中，Agent通过工具与世界交互。但工具越强，破坏力越大。
一个合格的Tool Registry，每个工具都至少要登记九项元信息：
| 元信息 | 说明 |
|---|---|
| 工具名称 | 唯一标识 |
| 工具描述 | 给LLM看的说明 |
| 输入参数JSON Schema | 用于校验 |
| 允许调用的Agent列表 | RBAC |
| 调用超时与速率限制 | — |
| 风险等级 | 低/中/高 |
| 是否需要人工确认 | — |
| 输出结果结构 | — |
| 审计日志策略 | 保存什么、保留多久、谁能看 |
这背后的思维转变很关键：
工具不是函数调用，而是生产资源的对外授权点。
你给Agent一个工具，等于给它一把权限钥匙。这把钥匙能开多少门、有没有时限、留不留痕、谁能审计——这些事必须从Day 1就想清楚。
MCP（Model Context Protocol）的出现让工具接入变得标准化，但标准化不等于安全。恰恰相反，工具越容易接入，越需要Harness在中间做安全网关。
MCP让工具接入变得便宜，Harness让工具调用变得可信。两者必须搭配，不可偏废。
04 基础设施层：从数据库到记忆系统
传统架构中，数据存储是确定性的：写入什么，读出什么。事务有ACID保证，查询有索引优化。
AI系统中，"记忆"是一个被严重浪漫化的词。很多文章会说Agent要像人一样积累经验。但生产环境里，记忆首先不是浪漫问题，而是工程问题。
它有四种典型的失败方式：
- 记得太少：每次都像第一次，无法复用经验
- 记得太多：上下文膨胀，检索噪声大，成本爆炸
- 不分层：临时数据和长期知识混在一起
- 不遗忘：过期信息长期污染决策
正确的做法是把"状态"和"记忆"分开：
**状态（State）**是当前任务运行所需的数据，生命周期短，关心一致性。分三层：
- Working State：当前步骤的临时上下文，任务结束即丢
- Session State：一次会话里多个Agent共享的信息，放Redis，设TTL
- Execution Log：不可变执行日志，不一定参与推理，但必须用于审计、回放、评估
**记忆（Memory）**是跨任务复用的经验和知识，生命周期长，关心相关性。分两类：
- Episodic Memory（事件记忆）：踩过的坑、用户偏好、某类问题处理经验
- Semantic Memory（语义记忆）：领域概念、业务规则、工具约束
Claude Code的七层记忆架构是当前最精巧的实现：从毫秒级的工具结果存储，到每轮对话前的微压缩，到实时维护的会话记忆，到上下文快满时的紧急压缩，到跨会话的长期知识提取，再到类似人脑睡眠的"做梦机制"巩固记忆，最后到多Agent间的跨代理沟通。
记忆不是仓库，而是花园。需要定期修剪。
05 从单Agent到Multi-Agent：职责分离的回归
过去两年，主流的AI Agent产品形态都是"一个全能助手"。这种形态在简单任务、个人工具、小型产品初级阶段时基本够用，但随着任务复杂度上升，缺少结构的代价越来越明显。
让同一个AI实例既当PM又当工程师又当法务，结果并不是三个角色都做得好。它在三个角色之间不断切换语境、不断丢上下文。它不是在协作，它是在自我对话。而自我对话天然就不太会给自己提反对意见。
Claude Code新推出的/goal功能，把裁判和运动员进行了分离：在每轮结束后，系统把目标条件和对话记录发给一个独立的小模型，由它来判断条件是否满足。
干活的归干活，验收的归验收。
Agent之间的协作，最重要的不是酷炫，而是把人类花了一百年发明的"职责分离+交叉校验"，重新装回去。
Helio这类产品正在押注这个方向：让AI以团队成员身份进入组织，有独立身份、独立邮箱、独立记忆、独立岗位。每个AI有明确的职责边界，就像真实公司里的JD——有自己该管和不该管的事、有该聚焦的和该放下的。
保留结构的好处，并去掉结构的代价。
06 成本控制：Token Budget是生命线
很多团队第一次跑通Agent时，最惊讶的不是模型能力，而是账单。
为什么Multi-Agent这么烧钱？
- 每个Agent都有System Prompt
- 每个Agent都需要上下文
- 工具结果会被塞回模型
- Planner生成计划，Worker执行步骤，Reviewer审查输出
- 失败后还要重试
- 多轮协作让历史不断复制膨胀
生产级Harness必须有Token Budget——它不是事后统计，而是实时调度：
| 区域 | 预算剩余 | 策略 |
|---|---|---|
| 绿区 | >50% | 正常执行 |
| 黄区 | 20%-50% | 压缩上下文 |
| 红区 | 5%-20% | 切小模型+跳过CoT |
| 熔断区 | <5% | 强制收束，返回partial result |
三个核心策略：
- Model Routing：不是所有步骤都需要最强模型。分类、摘要、格式转换用小模型；复杂推理、最终合成用强模型
- Context Compression：保留最近几轮原文+把更早历史压缩成结构化摘要
- Budget分级降级：从绿区到熔断区，逐步收紧
07 评估体系：不要只看答案，要看轨迹
Multi-Agent系统的评估，是目前被低估最严重的环节。
如果只看最终答案，会漏掉很多危险信号：
- 最终报告对了，但中间用了未授权的数据源
- 最终代码能跑，但Agent调用了十几次无意义工具
- 最终回答完整，但关键事实来自错误检索
- 某次结果成功，只是因为重试撞上了正确答案
生产级Eval Pipeline应至少分四层：
- Component Eval：单Agent是否选对工具、参数是否合规
- Trajectory Eval：步骤是否必要、顺序是否合理、是否重复调用
- Task Completion Eval：是否满足用户目标、是否存在事实错误
- End-to-End Eval：用户是否采纳、人工返工率、单位任务成本
Eval必须进入CI。每次改Prompt、换模型、加工具、调参数，都要跑回归。对Agent系统来说，Prompt就是代码，工具Schema就是接口，执行轨迹就是日志，Eval就是测试体系。
08 开发方法的回归：Specification-First
有趣的是，AI不仅改变了系统架构，也在改变开发方法本身。
Agile出现于一个规划困难、构建缓慢、需求感觉不可知的世界。在那个世界里，它是合理的适应。但AI改变了两个前提：
- 人类不擅长全面规划 → AI可以帮你规划，以先前不切实际的一致性和详细程度
- 构建缓慢且昂贵 → AI让构建速度提升了10-100倍
AI对上下文贪婪，且用全面规范奖励显著更好的输出。给它两句话的用户故事，得到两句话的解决方案；给它完整的架构文档、数据模型、依赖图，输出完全不同。
Agile围绕人类认知限制设计——人类无法在脑中持有大型复杂系统。AI不受此限制。给它小的、脱离上下文的片段不是"敏捷"——而是在削弱你最强大的工具。
新的方法是Specification-First, Iteration-on-Feedback：
- 前期投入架构，投资完整范围文档
- 用AI帮助规划
- 然后构建，在验证真实世界时纳入客户反馈
消亡的是规划厌恶和仪式经济。存活的是反馈循环，剔除多年来积攒的无用形式主义。
09 落地路线：分三阶段演进
不要想一步到位。
Phase 1 — MVP：跑通一条端到端业务闭环。最小Orchestrator + Tool Registry + 简单状态 + 基础Trace + 评估数据集。不要一开始就上动态Planner、十个Agent、复杂长期记忆。先把一条链路跑稳。
Phase 2 — Hardening：把Demo变成可控系统。增加Budget、权限、重试、压缩、轨迹评估、审计、回归测试。重点解决"为什么错、哪里贵、哪里慢、哪里不安全"。
Phase 3 — Scale：支撑更多场景与并发。引入分布式队列、多租户隔离、动态模型路由、Agent质量排行榜、A/B测试、长期记忆治理、统一MCP接入平台、成本看板。
技术选型上的务实建议：
- 小团队：LangGraph或自研轻量状态机 + FastAPI + Redis + PostgreSQL/pgvector + Langfuse + LiteLLM网关
- 企业团队：必须更重视权限、审计、多租户、成本中心、数据治理
- 研究团队：可以探索动态Planner、自反思、自动Eval，但务必区分研究效果和生产SLA
结语：靠谱比聪明更重要
回到Claude Code源码泄漏的故事。那个.map文件忘了排除，不是因为AI不够聪明，也不是因为程序员不够细心——只是因为流程上，缺了一个角色去基于自己的岗位职责，问出那个问题。
AI时代的系统架构，不是要消灭结构，而是要重新发明结构。
传统架构解决的是确定性问题：输入确定、逻辑确定、输出确定。 AI架构解决的是不确定性问题：输入模糊、推理概率、输出多变。
所以我们需要Orchestrator来接管决策，需要Tool Registry来约束工具，需要记忆系统来管理经验，需要Token Budget来控制成本，需要Eval Pipeline来保证质量，需要Multi-Agent来实现职责分离。
这些不是可选的装饰，而是AI系统从Demo走向生产的必经之路。
好的工程师不是在调教模型，而是在设计环境。
模型可以很强，但没有Harness的模型就像一个能力超群但没有工作台的工匠，再好的手艺也发挥不出来。
在工程世界里，靠谱比聪明更重要。
本文参考了多篇关于AI架构、Agent工程化、Multi-Agent Harness的深度分析，结合个人实践思考而成。
← 返回文章列表