跳转至

《从零实现 Agent 系统》连载 01｜Agent 系统是什么：问题空间与架构切片

Ch04.404 《从零实现 Agent 系统》连载 01｜Agent 系统是什么：问题空间与架构切片

📊 Level ⭐⭐ | 5.8KB | entities/agent-system-zero-to-one-01-architecture-slices-2026.md

《从零实现 Agent 系统》连载 01｜Agent 系统是什么：问题空间与架构切片

先分清一件事：你在接模型，还是在做一套能跑的「系统」

接一次大模型，本质是换一段上下文、拿回一段文字。它不管上一秒会话里承诺过什么，也不管这次要不要写库、能不能调外部接口、出了问题谁来背锅。业务一旦变成多步、带副作用、多人多租户、还要事后追责，你就得按长期在线的程序来设计——靠在同一 HTTP 里多打几次推理，补不齐这些窟窿。 大家口语里叫 Agent 系统，名字随便。关键是：你有没有把状态、编排、工具怎么出门、策略与记账、运维能不能伸手当成正经架构问题，而不是堆在 prompt 里。多平面听起来玄，其实就是几类责任不要糊成一锅：谁在算、谁在管风险、谁接人、谁管后台与存储，彼此用清晰的依赖方向约束，以后才改得动。

三个借来的「尺子」：操作系统、控制论、容器思维

深度分析

1. 接模型 ≠ 做系统：根本范式转变

单次 LLM 调用本质是「换上下文 → 取回文字」，它不保留会话承诺、不管写库调接口、出问题无人负责。一旦业务进入多步、带副作用、多人租户、事后追责场景，就必须按长期在线的程序来设计。靠同一 HTTP 里反复调用推理，补不上状态丢失、边界不清的窟窿。

2. 多平面架构：分离关注点是防御性设计核心

"多平面"不是什么玄学，而是要求把状态管理、编排逻辑、工具出口、策略记账、运维介入当作正经架构问题。核心是搞清楚：谁在算、谁在管风险、谁接人、谁管后台存储，彼此依赖方向要清晰，未来才改得动。

3. 三把架构尺子各有分工：OS 视角管运行时边界，控制论管闭环与合规，容器思维管配额与隔离

  • OS 尺子：谁在跑、能否优雅打断、出口是否走固定入口 → 对应网关、会话编排、沙箱、工具契约
  • 控制论尺子：目标=给定值，工具执行是真正能动手的过闸方 → 合规审批、内容检查应是并联闭环
  • 容器尺子：配额、不可变配置快照、默认收紧出站 → 类比租户硬隔断、分层镜像

4. 薄门面 + 厚中间层：依赖方向约束是包结构的灵魂

HTTP/CLI 只是字节翻译器，真正业务逻辑在协调与治理层。包名分层不是为了炫技，而是用语言层面说死谁不许反向依赖谁——领域模型不沾数据库类型，编排层不把业务叙事写死在路由里。

5. Demo 到 Production 差的不是 prompt，是整层治理

最小 demo：进来 → 过网关 → 跑 loop → 碰工具。企业级还需：治理与安全、异步后台、控制面、可替身存储。治理、评测、审计、预算这些「苦活」不做，系统只是玩具。

实践启示

  1. 先画架构盒子再写代码：用 OS/控制论/容器三把尺子把图画出来，让团队对「谁依赖谁、谁管什么」达成共识再动手

  2. 入口只做翻译，业务逻辑全放中间层：facade 层不写任何业务判断，所有策略、编排、账务逻辑在 core/coordination/governance 层展开

  3. 治理平面要独立，与推理路径并联：审批、发布门、内容检查不应是「模型更懂事就做完」的把戏，而是带清晰接口的闭环组件

  4. 包结构即依赖方向，乱了就说明边界没想清楚：每次想写 import 前先问「这个依赖是否符合既定层次？」，包依赖混乱是架构腐化的早期信号

  5. 上线前必补四件事：治理与安全、异步与后台、控制面、可替身存储——不是每面都要独立部署，但箭头方向和知情边界必须想清楚

相关实体

→ 原文存档