Agent参考架构
Q6:如何定义和度量 Agent 完成率?答(60–90s):先定义(机器可验优先),如「订单号已返回且状态=已发货」。、平均steps$/task、人工接手率。发布用 golden set + 回归 eval,见06。
Agent 参考架构
定位:将
05-architecture/architecture-views六视图方法论 扩展为 Agent 系统的 七视图(业务 / 应用 / 数据 / 部署 / 安全 / 集成 / 演进),供 Staff / Architect 白板、评审与落地对齐。
0. 面试前 30 分钟 Checklist(Staff / Architect)
| 时间盒 | 动作 | 产出 |
|---|---|---|
| 5 min | 背 七视图一句话(§1.2) | 能按序点名 7 张图 |
| 5 min | 白板 应用视图 七块(§3) | 控制面/数据面/护栏/观测/记忆/工具/路由 |
| 5 min | 画 演进阶梯(§8) | 单 Agent → 多 Agent → +Workflow → Mesh |
| 5 min | 口述 集成三板斧(§7) | API 同步 + Kafka 异步 + Outbox 写副作用 |
| 5 min | 准备 1 个 STAR-M-P(§12) | 含 M(机制修复)与 P(指标) |
| 5 min | 过 Master P0(§13)标红 3 项 | 知道回哪篇补课 |
开场金句(90s):
「Agent 不是 Chatbot 加长上下文,而是 带副作用的多步控制器。我会用 七视图 讲清楚:业务上解决什么能力、应用上控制面与数据面怎么分、数据上 checkpoint 与向量库怎么分、部署上模型 Serving 与 Agent Runtime 怎么扩、安全上四层防御横切、集成上怎么接微服务与 Saga/Outbox、演进上从单 Agent 到 Agent Mesh 怎么分期。」
1. 七视图方法论与六视图映射
1.1 为什么 Agent 需要第七视图「演进」
传统 architecture-views 六视图描述 稳态系统;Agent 在 2024–2026 快速迭代——框架、MCP、多 Agent、低代码 Workflow、未来 AI Gateway 并存。演进视图 单独回答:
- 现在 跑什么形态(单循环 / 图 / 多角色)?
- 下一季 迁移路径与兼容契约?
- 技术债 如何量化(prompt 版本、tool schema 漂移、eval 回归)?
其余六视图与 TOGAF Phase C/D 对齐;安全视图横切 所有视图(同母版 §6)。
1.2 七视图一句话速记
| # | 视图 | 核心问题 | Agent 特化关键词 |
|---|---|---|---|
| 1 | 业务 | 做什么、价值在哪 | 能力域、HITL 边界、可验收任务 |
| 2 | 应用 | 谁来做、怎么组合 | 控制面/数据面、Planner、Tool Router |
| 3 | 数据 | 存什么、怎么流 | Checkpoint、向量库、Artifact、Audit |
| 4 | 部署 | 怎么跑、怎么扩 | Runtime Pod、vLLM、GPU/CPU 池、多租户 |
| 5 | 安全 | 怎么防、怎么审 | 注入、工具滥用、PII、策略即代码 |
| 6 | 集成 | 怎么接存量系统 | BFF、Mesh、Outbox、Saga、IDP |
| 7 | 演进 | 怎么分期上 | 单 Agent → 多 Agent → Workflow → Mesh |
1.3 视图依赖关系(总图)
Staff 画法顺序(45min 白板推荐):业务(5m) → 应用(10m) → 数据(5m) → 集成(8m) → 部署(5m) → 安全(5m) → 演进(5m) → 风险收尾(2m)。
2. 业务视图(Business View)
2.1 能力地图 L1–L3(Agent 平台视角)
| L2 能力 | 典型用户 | 副作用级别 | 默认 HITL | 深链 |
|---|---|---|---|---|
| 客服问答 | C 端 / 商家 | 低(只读为主) | 写操作必审 | 18 §场景 CS |
| 告警 Triage | On-call | 中(ack/resolve) | critical resolve 必审 | 13 §20 |
| Buy 导购 | 店员 / App | 中(券/库存读) | 定价/支付禁自动 | 18 |
| 离线批处理 | 数据平台 | 高(DDL/DML) | 全批准入 + checkpoint | 21 §6 |
2.2 价值流与验收标准
价值流(客服 Agent 示例):
| 验收维度 | 机器可验 | 人工可验 | 反模式 |
|---|---|---|---|
| 任务完成 | success_criteria 全绿 |
抽检对话 | 「感觉答完了」无标准 |
| 业务正确 | tool JSON 与回答一致 | 政策抽检 | 模型编造金额 |
| 合规 | Guardrails pass | 审计日志 | 仅靠 system prompt |
| 成本 | $/task ≤ 预算 |
FinOps 周报 | 无 token 上限 |
2.3 业务视图反模式
| 反模式 | 现象 | 正确做法 |
|---|---|---|
| 万物 Agent | FAQ 也上 ReAct | RAG + 模板;固定流用 Workflow |
| 无 Owner 能力 | 谁都能加一个 tool | 能力域注册表 + ADR |
| 验收不可测 | 「用户满意」无指标 | completion_rate + citation_rate |
| 忽视人工链路 | Agent 直接改生产 | HITL 分级写入控制面 |
3. 应用视图(Application View)
核心:应用视图是 Staff 面试 停留时间最长 的视图。必须能画 控制面 / 数据面 / 护栏 / 观测 / 记忆 / 工具 / 路由 七组件及 组件契约、SLA、降级。
3.1 参考架构总图
3.2 组件契约与 SLA
| 组件 | 职责边界 | 可用性 SLA | 延迟 SLA | 降级策略 | 反模式 |
|---|---|---|---|---|---|
| 控制面 Control Plane | AUTH+POL+BUD+HITL+IDEM | 99.99% | p99 <50ms | 拒绝未授权/超预算任务入队 | 策略放 prompt;无幂等登记 |
| Agent Runtime | RT | 99.9% | 单任务 wall p99 <120s | 队列积压→降级为只读 FAQ | 与 LLM 同进程无隔离 |
| Planner | PL | 99.5% | plan 生成 <8s | 超时→固定 SOP 模板 plan | 一次生成 50 步大 plan |
| Executor | EX | 99.9% | 单步 tool p99 <3s | 步级 verify 失败→replan≤2 | 无 verify 闸门 |
| Tool Router | TR | 99.95% | 路由 <20ms | tool 不可用→备选 tool/缓存 | 任意 tool 无 schema 校验 |
| LLM Router | LLM | 99.5% | TTFT p99 <2s | 降级小模型/缩短上下文 | 无 model fallback |
| Guardrails | GR | 99.99% | 校验 <100ms | block→模板拒答+工单 | 仅 system prompt |
| Observability | OBS | 99.9% | trace 完整率 >99% | 采样降档不断 trace_id | 无 step 级 replay |
| Memory | MEM | 99.9% | 读 p99 <50ms | 向量超时→跳过长期记忆 | checkpoint 放 Pod 内存 |
| RAG | RAG | 99.5% | 检索 p99 <200ms | 超时→关键词检索 | 与 checkpoint 混表 |
3.3 控制面 · 工程细节
| 能力 | 实现要点 | 与 21 对齐 |
|---|---|---|
| 身份/租户 | JWT + tenant_id 贯穿 trace |
§3.1 Gateway |
| Policy-as-Code | OPA/Rego:risk_level(write) → HITL |
17 §5 |
| 预算 | max_steps / max_cost_usd / token cap |
13 §2.2 |
| 幂等 | idempotency_key = entity:op:generation |
21 §4.2 |
| HITL | 队列 + 超时升级;审批写回 checkpoint | 13 §8 |
3.4 数据面 · Planner / Executor / 有界循环
推荐生产默认:DAG 骨架 + 局部 ReAct(非纯 ReAct 无限循环)。
| 模式 | 状态机 | 适用 | 见 |
|---|---|---|---|
| ReAct | 单环 Think→Act→Observe | 探索型 PoC | 04 §4 |
| Plan-Execute | plan 一次→逐步执行 | 步骤稳定 | 13 §2 |
| DAG+有界环 | 阶段 DAG;阶段内 ≤N 步 | 生产默认 | 本篇 + 21 §6 |
Executor 契约(每步):
Input: { step_id, tool_name, args, context_digest, version_pin }
Output: { observation, status, verify_result, artifacts?, error? }
Invariant:
- 同 (tool,args) 连续失败 ≥3 → circuit_break
- verify 失败 → replan 或 HITL(按 risk)
- 写操作必须带 idempotency_key(控制面签发)
3.5 工具平面 Tool Router + MCP
| 契约项 | 要求 |
|---|---|
| Schema | OpenAPI / JSON Schema 版本化 tool_schema_rev |
| 分类 | read / write / admin 标签;write 走 HITL |
| 超时 | 读 3s / 写 10s;可配置 per tool |
| 结果大小 | >32KB → Artifact Store URI 引用 |
| 审计 | 参数摘要入 Audit(非全量 PII) |
→ MCP/A2A 详见 04 §12。
3.6 记忆平面 Memory
| 类型 | 存储 | 生命周期 | 禁止 |
|---|---|---|---|
| Working | Runtime state | 单任务 | 把整段 history 塞 prompt |
| Checkpoint | PostgreSQL | 任务级持久 | 用 trace_id 当写幂等键 |
| Session | Redis | 24h TTL | 跨租户共享 key |
| Semantic | pgvector | 长期 | 与 checkpoint 混表 |
| Episodic | Redis + PG 摘要 | 30d | 无版本的政策 chunk |
→ Context Engineering 详见 04 §13、13 §3。
3.7 路由平面 LLM Router
| 路由维度 | 策略 | 配置源 |
|---|---|---|
| 任务类型 | 分类用小模型 → 路由大模型 | LiteLLM alias |
| 成本 | 超预算 → 降级 Haiku 级 | 07 §10 |
| 延迟 | TTFT 恶化 → 缩短 max_tokens | Serving 指标 |
| 合规 | 区域数据 → 指定 endpoint | 控制面 tenant policy |
降级矩阵:
| 级别 | 触发 | 行为 |
|---|---|---|
| L0 正常 | — | 全功能 |
| L1 成本 | 80% 日预算 | 禁 Multi-Agent 并行 |
| L2 延迟 | TTFT p99>3s | 强制短上下文 + 小模型 |
| L3 依赖 | LLM 5xx | 模板 FAQ + 人工排队 |
| L4 事故 | Guardrails 大规模 fail | 只读模式全局开关 |
3.8 护栏 Guardrails
| 阶段 | 检查 | 失败动作 |
|---|---|---|
| 输入 | 注入检测、PII 扫描 | 拒答 / 脱敏 |
| 工具前 | 参数 schema + 风险 | block write |
| 输出 | JSON schema、引用、citation | 重试一次 → 拒答 |
| 事后 | 抽检 + 红队 | 版本回滚 |
→ 技术栈 17 §4;Spring AI Advisor 18 §0.2。
3.9 可观测 Observability
| 信号 | 最小字段 | SLO |
|---|---|---|
| Trace | trace_id, task_id, step_id, tool, model_rev |
99% 完整 |
| Metrics | $/task, steps, tool_errors, completion_rate |
仪表盘 24h |
| Audit | 谁批准 HITL、写了什么实体 | 7 年留存(合规域) |
| Eval | 版本对比 golden set | 发布门禁 |
3.10 应用视图反模式
| 反模式 | 风险 | 修复 |
|---|---|---|
| 控制面空心化 | prompt 里写「不要退款」 | Policy + tool 标签 + HITL |
| 数据面有状态 Pod | 重启丢进度 | Checkpoint 外置 PG |
| 护栏后置 | 有害内容已返回用户 | 输出 schema 校验 |
| 观测只有日志 | 无法 replay 第 N 步 | step 级 span |
| 工具无版本 | schema 漂移导致参数幻觉 | version_pin |
4. 数据视图(Data View)
4.1 逻辑数据模型
4.2 存储选型矩阵
| 数据类 | 技术 | 一致性 | 分区键 | 非 Agent 常见误区 |
|---|---|---|---|---|
| Checkpoint | PostgreSQL | 强一致 | task_id |
误用 Redis 无持久 |
| Artifact | S3/OSS | 最终 | task_id/step_id |
塞 PG BLOB |
| Session | Redis | 最终 | tenant:session |
无 TTL |
| 向量索引 | pgvector/Milvus | 最终 | tenant+kb |
无 kb_version |
| Audit | ClickHouse/ES | append | day+tenant |
与 trace 未关联 |
| Eval 集 | PG + 对象存储 | — | suite_rev |
无版本 pin |
→ RAG 管线 03;checkpoint 字段 21 §4。
4.3 数据流(在线任务)
写路径原则:业务副作用 只通过 Tool 调微服务;Agent 侧 不直写业务库(防腐层)。
4.4 数据治理
| 维度 | Agent 特化要求 |
|---|---|
| 分类分级 | conversation=P2;audit=P3;tool 结果含 PII 脱敏 |
| 留存 | session 30d;audit 按合规;checkpoint 任务完成后 90d 归档 |
| 质量 | citation_rate, faithfulness 入质量仪表盘 |
| 血缘 | version_pin: prompt+model+kb+tool_schema |
| 删除权 | 用户删号 → 向量+session+checkpoint 级联擦除 |
反模式:向量库无租户隔离;checkpoint 存全量 tool JSON 撑爆 PG。
5. 部署视图(Deployment View)
5.1 部署拓扑
| 组件 | 副本策略 | HPA 信号 | 见 |
|---|---|---|---|
| Gateway | min 3 跨 AZ | QPS / 429 | 07 |
| Runtime | CPU 60% 或队列深度 | 自定义 queue_depth |
21 §8 |
| LiteLLM | 无状态 2+ | 延迟 | 07 §10 |
| vLLM | GPU 占满率 | TTFT / KV 利用率 | 07 §3 |
5.2 环境策略
| 环境 | LLM | 数据 | 发布 |
|---|---|---|---|
| dev | 共享 cheap 模型 | 脱敏副本 | 任意 |
| staging | 生产同 schema 小流量 | 合成+抽样真数据 | eval gate |
| prod | 多模型路由 | 真数据分级 | 金丝雀 + prompt rev |
反模式:staging 无 eval gate;prod 直接改 prompt 无 version_pin 回滚。
5.3 多租户与隔离
| 层级 | 隔离方式 |
|---|---|
| 网络 | Namespace per 大租户 / Mesh AuthorizationPolicy |
| 数据 | tenant_id 行级 + 向量 metadata 过滤 |
| 算力 | 预算配额 + 独立 queue |
| 模型 | LiteLLM key per tenant |
6. 安全视图(Security View · 横切)
6.1 STRIDE 映射(Agent 特化)
| STRIDE | Agent 威胁 | 控制 |
|---|---|---|
| S | 伪造 Webhook 触发任务 | mTLS + HMAC 签名 |
| T | 篡改 tool 响应 | TLS + 响应签名(高敏) |
| R | 普通用户提权调 admin tool | RBAC + OPA |
| I | 注入泄露其他租户 session | 租户隔离 + 最小上下文 |
| D | 疯狂调 LLM 打穿预算 | 限流 + 预算熔断 |
| E | 审计日志被删 | append-only + SIEM |
→ 四层防御 17 §2。
6.2 纵深防御(Agent 栈)
| 层 | 必答面试点 |
|---|---|
| L3 | 写操作不能只在 prompt 禁止 |
| L5 | MCP server 也要鉴权 |
| L6 | 金额/库存必须来自 tool JSON |
6.3 安全视图反模式
| 反模式 | 案例锚点 |
|---|---|
| prompt 当防火墙 | 13 §15.1 误退款 |
| trace_id 幂等 | 04 §8 退款重试 |
| 工具过度授权 | 客服 Agent 带 admin_* tool |
7. 集成视图(Integration View)
7.1 与企业架构对齐
| 集成模式 | 用于 | Agent 注意点 |
|---|---|---|
| 同步 API | 读多写少、低延迟 | 超时 + 熔断;缓存读 |
| 异步事件 | 状态通知、解耦 | 消费幂等;与 Agent 任务 id 关联 |
| Outbox | Agent 触发业务写 | 业务库与 outbox 同事务 |
| Saga | 多步写跨服务 | 补偿步骤人审或脚本 |
| Workflow | 固定审批链 | Agent 生成草案,Workflow 执行 |
7.2 微服务与 Service Mesh
| 能力 | Mesh 提供 | Agent 用法 |
|---|---|---|
| mTLS | 服务间加密 | Tool 调域内 gRPC |
| 流量 | 金丝雀 | Runtime 新版本 5% |
| 授权 | AuthorizationPolicy | 限制 Runtime→支付域 |
| 观测 | trace 传播 | 跨 Agent→订单服务 |
→ mesh、governance。
7.3 AI Gateway(规划 24)契约预留
| 能力 | 统一入口价值 | 本篇占位 |
|---|---|---|
| 模型路由 | 租户级 quota | Header X-Model-Route |
| Prompt 注册 | 版本化 | prompt_rev in version_pin |
| Tool 注册 | 中心化 schema | Tool Router 拉取 |
| 策略 | 全链路 Guardrails | 与 17 合并 |
7.4 IDP 与平台工程
| IDP 能力 | Agent 团队消费 |
|---|---|
| 模板仓库 | agent-service-springai golden path |
| 密钥 | Vault 注入 LITELLM_API_KEY |
| 观测 | 自动注册 dashboard |
| 发布 | ArgoCD + eval gate |
→ microservices-governance §07 IDP。
7.5 Saga + Outbox 与 Agent 写操作
原则:Agent 不充当 分布式事务协调器;长事务用 Saga,单服务写用 Outbox。
| 步骤 | 谁编排 | Agent 角色 |
|---|---|---|
| 提议退款 | Agent | 生成参数 + 证据 |
| 执行退款 | 订单服务 API | 调用一次;不循环重试乱改 key |
| 后续库存 | Saga 订阅者 | 不让 LLM 直接调库存写 |
反模式:Agent 逐步调 5 个写 API 无 Saga;Outbox 未用导致双写不一致。
7.6 集成视图反模式
| 反模式 | 后果 |
|---|---|
| Agent 直连核心库 | 绕过领域边界 |
| 无防腐层 | schema 变更击穿 prompt |
| 用 Chat 接口做批处理 | 无 checkpoint 巨贵 |
8. 演进视图(Evolution View · 第七视图)
8.1 四阶段 maturity ladder
| 阶段 | 特征 | 准入门槛 | 典型技术债 |
|---|---|---|---|
| 1 单 Agent | 一个 Runtime;DAG+≤8 步 | 有 checkpoint+trace | prompt 散落代码 |
| 2 多 Agent | Planner+Worker+Verifier | 单 Agent completion≥80% | 协调者 token 爆炸 |
| 3 +Workflow | 固定段 Camunda;可变段 Agent | 写操作全 HITL 或 Saga | 双编排打架 |
| 4 Agent Mesh | 跨域 Agent 注册发现;策略联邦 | AI Gateway+统一 eval | 无租户策略 |
→ 分期与 16 原型到生产 对齐。
8.2 迁移策略(Strangler for Agent)
| 遗留 | 目标 | 手法 |
|---|---|---|
| 规则客服 | Agent 只读辅助 | 并行流量 5% shadow |
| 单体会话 | 独立 Agent Svc | BFF 路由切换 |
| Dify 工作流 | Spring AI | 导出 DAG → 代码化 |
| 直连 OpenAI | LiteLLM | 改 base-url |
8.3 版本与兼容契约
| 工件 | 版本策略 | 破坏兼容时 |
|---|---|---|
prompt_rev |
semver | eval 回归才升 major |
tool_schema_rev |
并存 2 版 30d | Agent 路由旧 schema |
kb_index_rev |
蓝绿索引 | 双读验证 citation |
model_alias |
LiteLLM 配置 | 灰度 10% 流量 |
8.4 演进视图反模式
| 反模式 | 后果 |
|---|---|
| 跳 Stage 2 上 Multi-Agent | 成本翻倍、completion 下降 |
| 无 eval gate 全量 | 线上幻觉事故 |
| Mesh 前无统一 trace | 跨域不可追 |
9. 跨视图一致性矩阵
| 决策 | 业务 | 应用 | 数据 | 部署 | 安全 | 集成 | 演进 |
|---|---|---|---|---|---|---|---|
| 上线写操作 Agent | HITL 必审 | 控制面 policy | audit 全量 | 独立队列 | write tool 标签 | Saga | Stage≥2 |
| 只读 FAQ | 无 HITL | 可纯 RAG | 无 checkpoint | 小副本 | 标准护栏 | 同步读 API | Stage 1 |
| 多 Agent | 角色清晰 | Coordinator | 共享 checkpoint 租户隔离 | HPA 按队列 | 跨 Agent 策略 | 事件总线 | Stage 2+ |
10. 45 分钟白板模拟题 · 满分参考答案
10.1 题目(面试官念)
设计一套 企业级客服 + 订单查询 Agent 平台,支持 App 与商家后台;可读订单/物流;退款/改址必须可控;日活 500 万,峰值 QPS 2 万(含非 Agent 流量);要可观测、可审计、可渐进从 FAQ 演进到 Agent。45 分钟。
10.2 时间盒
10.3 需求澄清(5 min)— 必问
| 问题 | 假设(写下来) |
|---|---|
| Agent 流量占比? | 峰值 2k QPS Agent(10%) |
| 写操作? | 退款/改址 禁止自动执行 → HITL |
| 延迟? | 读链路 p99 <3s(含 RAG+1 次 tool) |
| 多租户? | 平台商家 + 自营;tenant_id 隔离 |
| 合规? | 对话留存 30d;audit 1y |
范围切割:做 Agent 平台 + BFF;不做订单核心重构;支付引用支付域 API。
10.4 满分答 · 业务视图(5 min)
L2 能力:查询(订单/物流)、建议(退款原因分析)、执行(仅 HITL 后)。
价值流:意图识别 → 只读 tool → 带 citation 回答;写意图 → 工单 + 人工。
验收:completion_rate;citation_rate≥80%;写操作 hitl_rate=100%。
10.5 满分答 · 应用视图(12 min)
画 §3.1 总图,强调:
- 控制面:JWT、OPA、
max_cost_usd、幂等登记、HITL 队列。 - 数据面:LangGraph/Spring AI;DAG 骨架;Planner 滚动 3–5 步。
- Tool Router:订单/物流 read;
suggest_refund只出草案;execute_refunddisabled 除非 HITL token。 - Guardrails:金额只信 tool JSON。
- Obs:
trace_idstep 级;$/task大盘。
口述 SLA:Gateway 99.99%;Runtime 99.9%;LLM 降级 L2/L3。
10.6 满分答 · 数据 + 集成(10 min)
- Checkpoint PG;Session Redis;向量 pgvector
kb_version。 - 集成:BFF → Mesh → 订单 gRPC;异步 Outbox 发
RefundRequested(非 Agent 直写库存)。 - Saga:退款编排由 订单域 消费事件驱动,Agent 不协调多写。
容量粗算:2000 QPS * 3k tokens * $0.003/1k ≈ $18/s 峰值 → 需缓存命中 + 小模型路由 + 预算熔断。
10.7 满分答 · 部署 + 安全 + 演进(13 min)
- 部署:K8s 双 AZ;Runtime HPA;LiteLLM → vLLM;staging eval gate。
- 安全:四层防御;STRIDE 表;客服 tool 最小权限。
- 演进:Stage1 只读 Agent 5% 流量 → eval 优于 FAQ 再扩;Stage3 退款走 Workflow+HITL。
收尾风险:LLM 超时、RAG 旧政策、tool 重试幂等 —— 各给一条降级。
11. 高频口述题 · 60–90 秒满分答(12 题)
11.1 Agent 和 Chatbot 架构本质区别?
Q1:Agent 和 Chatbot 架构本质区别?
答(60–90s):Chatbot 以 单轮生成 为中心,状态主要是会话历史;Agent 是 带副作用的多步控制器,必须有 tool、验收标准、checkpoint、控制面策略。生产上 Agent 需要 step 级 trace、幂等写、HITL,成本模型按 $/task 而不是 $/message。
11.2 控制面和数据面为什么要分?
Q2:控制面和数据面为什么要分?
答(60–90s):控制面处理 能不能做(身份、预算、风险、审批、幂等登记),要快、要确定性;数据面处理 怎么做(plan、LLM、tool),可以弹性扩缩。混在一起会导致策略散落 prompt、无法审计、无法对写操作做统一熔断。
11.3 生产默认为什么推荐 DAG+有界循环而不是纯 ReAct?
Q3:生产默认为什么推荐 DAG+有界循环而不是纯 ReAct?
答(60–90s):纯 ReAct 容易 死循环、短视、成本不可控;DAG 把确定性业务流程固化,只在局部用 ReAct 处理观测异常。配合 max_steps、同 tool 熔断、verify 闸门,SLO 可签。见 13 §2。
11.4 Checkpoint 和向量库有什么区别?
Q4:Checkpoint 和向量库有什么区别?
答(60–90s):Checkpoint 存 任务状态机(plan、completed_steps、version_pin),PostgreSQL 强一致;向量库存 语义记忆和 RAG,最终一致。混用会导致续跑失败或检索慢拖垮主路径。见 21 §3.2。
11.5 Agent 写操作为什么必须 HITL 或 Saga?
Q5:Agent 写操作为什么必须 HITL 或 Saga?
答(60–90s):LLM 非确定性,不能作为分布式事务协调器。写操作要么 人审(客服退款),要么 领域服务+Outbox/Saga(订单域编排)。Agent 只应提交 幂等、可审计 的一次请求。
11.6 如何定义和度量 Agent 完成率?
Q6:如何定义和度量 Agent 完成率?
答(60–90s):先定义 success_criteria(机器可验优先),如「订单号已返回且状态=已发货」。指标:completion_rate、平均 steps、$/task、人工接手率。发布用 golden set + 回归 eval,见 06。
11.7 Multi-Agent 什么时候值得上?
Q7:Multi-Agent 什么时候值得上?
答(60–90s):当 子任务可并行、上下文可隔离、角色 skill 差异大 且单 Agent completion<目标;否则 Coordinator token 开销会让成本上升。准入:单 Agent eval≥80%。见 04 §5。
11.8 Guardrails 和 system prompt 边界?
Q8:Guardrails 和 system prompt 边界?
答(60–90s):system prompt 是 软约束,模型可能违反;Guardrails 是 硬校验(schema、注入检测、PII、引用来源)。金额/库存/政策必须 tool JSON + citation,失败拒答。见 17 §4。
11.9 Agent 平台怎么做多租户?
Q9:Agent 平台怎么做多租户?
答(60–90s):链路贯穿 tenant_id:Gateway、checkpoint 行级、向量 metadata 过滤、LiteLLM key 配额、Mesh AuthorizationPolicy。删除权要级联擦除 session+向量+checkpoint。
11.10 和微服务集成时防腐层怎么画?
Q10:和微服务集成时防腐层怎么画?
答(60–90s):Agent 只调 BFF/领域 API,不直连库。API schema 版本进 version_pin;下游变更由适配层吸收,避免 prompt 里塞 SQL/表结构。
11.11 演进 Stage 1→2 的最大风险?
Q11:演进 Stage 1→2 的最大风险?
答(60–90s):多 Agent 协调成本与一致性:重复规划、互相矛盾 observation。治理上要有单一 Coordinator、共享 checkpoint、统一 eval,否则 completion 和成本双恶化。
11.12 AI Gateway(24)上线后 Agent 架构怎么变?
Q12:AI Gateway(24)上线后 Agent 架构怎么变?
答(60–90s):模型路由、prompt 注册、tool 注册、全局策略 外提到 Gateway;Runtime 变薄,专注编排与状态。迁移期双写路由头,灰度租户。
12. STAR-M-P 事故复盘:Agent 平台跨租户记忆泄漏
| 字段 | 内容 |
|---|---|
| S | 某多租户客服 Agent 上线 3 天后,商家 A 会话出现商家 B 的订单尾号与金额片段,客服截图外传,监管问询。 |
| T | 24h 内止血并证明影响面;7 天内修复机制防复发。 |
| A | 立即关闭跨 session 语义记忆召回;按 tenant_id 扫 audit 影响 127 会话;trace 显示 pgvector 检索 未带 tenant filter,且 Mem0 同步 job 写入了错误 namespace;回滚 mem_sync job,热修 Router 强制 metadata filter;补 eval 用例「跨租户泄露」100 条。 |
| R | 0 新增泄漏 72h;对外公告影响 127 会话;商家补偿流程启动。 |
| P | cross_tenant_retrieval_rate 实时告警;周级红队;租户隔离纳入 P0 发布门禁。 |
| M | ① 向量检索 API 强制 tenant_id 入参,缺失则拒绝;② Checkpoint/Session key 加租户前缀;③ 记忆写入双写校验 namespace;④ CI 集成跨租户 eval。 |
根因链:应用视图 Memory 组件契约缺失 → 数据视图向量 metadata 未治理 → 安全视图 I 威胁未测。
13. Master Checklist(P0 / P1 / P2)
13.1 P0 — 上线阻断(必须全绿)
- P0-01 控制面:写操作 risk 标签 + HITL/Policy
- P0-02 幂等:写 API 用 business idempotency_key(非 trace_id)
- P0-03 Checkpoint:PostgreSQL 外置,任务可 resume
- P0-04 护栏:输出 schema + 金额/库存仅 tool JSON
- P0-05 观测:trace_id + step 级 span 完整率>99%
- P0-06 租户:向量/ session / checkpoint 全链路 tenant_id
- P0-07 预算:max_steps + max_cost_usd 硬熔断
- P0-08 工具:schema 版本化;write tool 默认禁或 HITL
- P0-09 集成:不直连业务库;写走领域 API/Outbox
- P0-10 eval:发布门禁 golden set 无回归
- P0-11 安全:注入检测 + audit append-only
- P0-12 降级:LLM 5xx / RAG 超时 / tool 熔断有 L1–L3
13.2 P1 — Staff 答辩强加分
- P1-01 能画七视图总图与依赖
- P1-02 能口述应用视图七组件 SLA
- P1-03 能讲 Stage1→4 演进与准入
- P1-04 能白板 Saga/Outbox 与 Agent 边界
- P1-05 有真实 $/task、completion_rate 数字
- P1-06 version_pin 含 prompt+model+kb+tool
- P1-07 Multi-Agent 有 Coordinator 与 eval 准入
- P1-08 Mesh mTLS + 授权策略示例
- P1-09 IDP golden path 与 eval gate
- P1-10 STAR-M-P 事故含 M 机制与 P 指标
13.3 P2 — 架构卓越(可选)
- P2-01 AI Gateway 24 契约已评审
- P2-02 Agent Mesh 联邦策略草案
- P2-03 跨域统一 eval 平台
- P2-04 FinOps 模型路由自动优化
- P2-05 红队季度化 + 自动化注入集
- P2-06 GraphRAG 与 Agent 规划结合 POC
- P2-07 A2A 跨组织 Agent 互操作试点
14. 附录 A:应用组件接口草案(OpenAPI 片段)
# Agent Control Plane - Task Submit (concept)
post /v1/agent/tasks:
headers:
Authorization: Bearer
X-Tenant-Id: required
X-Idempotency-Key: required-for-write-intent
body:
goal: string
success_criteria: string[]
scene: enum [cs, ops, buy]
risk_profile: enum [read_only, suggest_write, execute_write]
responses:
202: { task_id, trace_id, status: queued }
403: policy_denied
429: budget_exceeded
15. 附录 B:数据表 DDL 摘要(Checkpoint)
CREATE TABLE agent_checkpoint (
task_id VARCHAR(64) PRIMARY KEY,
tenant_id VARCHAR(32) NOT NULL,
rev INT NOT NULL DEFAULT 1,
trace_id VARCHAR(64) NOT NULL,
goal TEXT NOT NULL,
success_criteria JSONB NOT NULL,
plan JSONB,
completed_steps JSONB DEFAULT '[]',
version_pin JSONB NOT NULL,
status VARCHAR(24) NOT NULL,
wall_time_spent_s INT DEFAULT 0,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX idx_checkpoint_tenant_updated ON agent_checkpoint(tenant_id, updated_at DESC);
16. 附录 C:与 05-architecture 六视图对照速查
| 05-architecture 视图 | 本篇 Agent 章节 | 增量 |
|---|---|---|
| 业务架构 01 | §2 | 验收标准、HITL 边界 |
| 应用架构 05 | §3 | 控制面/数据面七组件 |
| 数据架构 04 | §4 | Checkpoint vs 向量 |
| 部署架构 03 | §5 | Runtime + vLLM |
| 安全架构 06 | §6 | 注入/工具滥用 |
| 技术架构 02 | §3.7/§5 | LiteLLM/路由 |
| — | §7 集成 | Outbox/Saga/Mesh/IDP |
| — | §8 演进 | 四阶段 maturity |
17. 附录 D:七视图面试追问矩阵(35 格)
| 视图 | 追问维度 | 锚点章节 | 准备要点 |
|---|---|---|---|
| 业务 | 容量 | §2 | 准备 1 个数字或策略 |
| 业务 | 一致性 | §2 | 准备 1 个数字或策略 |
| 业务 | 失败 | §2 | 准备 1 个数字或策略 |
| 业务 | 成本 | §2 | 准备 1 个数字或策略 |
| 业务 | 合规 | §2 | 准备 1 个数字或策略 |
| 应用 | 容量 | §3 | 准备 1 个数字或策略 |
| 应用 | 一致性 | §3 | 准备 1 个数字或策略 |
| 应用 | 失败 | §3 | 准备 1 个数字或策略 |
| 应用 | 成本 | §3 | 准备 1 个数字或策略 |
| 应用 | 合规 | §3 | 准备 1 个数字或策略 |
| 数据 | 容量 | §4 | 准备 1 个数字或策略 |
| 数据 | 一致性 | §4 | 准备 1 个数字或策略 |
| 数据 | 失败 | §4 | 准备 1 个数字或策略 |
| 数据 | 成本 | §4 | 准备 1 个数字或策略 |
| 数据 | 合规 | §4 | 准备 1 个数字或策略 |
| 部署 | 容量 | §5 | 准备 1 个数字或策略 |
| 部署 | 一致性 | §5 | 准备 1 个数字或策略 |
| 部署 | 失败 | §5 | 准备 1 个数字或策略 |
| 部署 | 成本 | §5 | 准备 1 个数字或策略 |
| 部署 | 合规 | §5 | 准备 1 个数字或策略 |
| 安全 | 容量 | §6 | 准备 1 个数字或策略 |
| 安全 | 一致性 | §6 | 准备 1 个数字或策略 |
| 安全 | 失败 | §6 | 准备 1 个数字或策略 |
| 安全 | 成本 | §6 | 准备 1 个数字或策略 |
| 安全 | 合规 | §6 | 准备 1 个数字或策略 |
| 集成 | 容量 | §7 | 准备 1 个数字或策略 |
| 集成 | 一致性 | §7 | 准备 1 个数字或策略 |
| 集成 | 失败 | §7 | 准备 1 个数字或策略 |
| 集成 | 成本 | §7 | 准备 1 个数字或策略 |
| 集成 | 合规 | §7 | 准备 1 个数字或策略 |
| 演进 | 容量 | §8 | 准备 1 个数字或策略 |
| 演进 | 一致性 | §8 | 准备 1 个数字或策略 |
| 演进 | 失败 | §8 | 准备 1 个数字或策略 |
| 演进 | 成本 | §8 | 准备 1 个数字或策略 |
| 演进 | 合规 | §8 | 准备 1 个数字或策略 |
18. 附录 E:术语表(中英)
| 术语 | 定义 |
|---|---|
| Agent Runtime | 执行 Plan/Tool/LLM 的有状态或无状态运行时 |
| Control Plane | 策略、预算、审批、幂等登记 |
| Data Plane | 规划与工具执行面 |
| Checkpoint | 任务状态持久化点,非向量库 |
| version_pin | prompt/model/kb/tool 版本快照 |
| HITL | Human-in-the-loop 人工审批 |
| Guardrails | 硬校验护栏,非 prompt |
| Agent Mesh | 跨域 Agent 注册、发现、策略联邦 |
| Outbox | 业务与消息同事务可靠投递 |
| North Star | goal + success_criteria 锚点 |
19. 附录 F:深度阅读路径(按岗位)
| 岗位 | 本周 | 下周 |
|---|---|---|
| Applied AI | 本篇 §3+§4 + 13 | 04 |
| AI Infra | 本篇 §5+§7 + 07 | mesh |
| Java 架构 | 本篇 §3+§7 + 18 | 14 |
| 安全/合规 | 本篇 §6 + 17 | 红队 §6.2 |
99. 章节导航
| 章 | 内容 |
|---|---|
| §0 | 30 分钟 Checklist |
| §1 | 七视图方法论 |
| §2 | 业务视图 |
| §3 | 应用视图(核心) |
| §4 | 数据视图 |
| §5 | 部署视图 |
| §6 | 安全视图 |
| §7 | 集成视图 |
| §8 | 演进视图 |
| §9 | 跨视图矩阵 |
| §10 | 45min 白板满分答 |
| §11 | 12 道口述题 |
| §12 | STAR-M-P |
| §13 | Master P0/P1/P2 |
| §14–19 | 附录 |
| §99 | 导航 |
下一步:若时间紧,先 §0 → §3 → §10 → §11 任选 5 题 → §13 P0;若冲 Architect,补 §7 Saga/Outbox + §8 演进 + 13 §19。
20. 附录 G:应用视图组件详表(扩展)
20.1 Gateway
| 属性 | Gateway 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.2 ControlPlane
| 属性 | ControlPlane 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.3 Runtime
| 属性 | Runtime 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 外置状态 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.4 Planner
| 属性 | Planner 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.5 Executor
| 属性 | Executor 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.6 ToolRouter
| 属性 | ToolRouter 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.7 LLMRouter
| 属性 | LLMRouter 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.8 Guardrails
| 属性 | Guardrails 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.9 Memory
| 属性 | Memory 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 外置状态 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.10 RAG
| 属性 | RAG 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
20.11 Observability
| 属性 | Observability 说明 |
|---|---|
| Owner | 平台团队 / 域团队 |
| SLA | 见 §3.2 |
| Scale | 水平扩展 |
| State | 无状态优先 |
| Failure | 熔断 + 降级 |
| Metrics | RED + 业务 KPI |
| Dependency | 见深链章节 |
21. 附录 H:业务场景模式库(10 模式)
| 模式 | risk | 工具 | HITL |
|---|---|---|---|
| 客服只读 | read_only | RAG+订单查询 tool | 无 HITL |
| 客服建议写 | suggest_write | 生成工单草案 | 人执行 |
| SRE Triage | read+ack | MCP 监控 tool | critical resolve HITL |
| Buy 导购 | read | 商品/库存 read | 定价 tool 禁用 |
| 数据迁移 | batch_write | 分区 checkpoint | 全准入评审 |
| 代码助手 | sandbox | 隔离执行 | 无 prod 网络 |
| 报表生成 | read+export | Artifact S3 | 大数据外置 |
| 审批助手 | workflow | Camunda 衔接 | Agent 不执行写 |
| 多 Agent 研究 | internal | 并行 Worker | 无外部写 |
| Red Team | offline | 合成攻击集 | 隔离环境 |
22. 附录 I:七视图反模式全集(42 条)
- AP-01 [业务] 无验收标准
- AP-02 [业务] 万物 Agent
- AP-03 [业务] 能力无 Owner
- AP-04 [业务] 忽视合规场景
- AP-05 [业务] ROI 无度量
- AP-06 [业务] 与 BPM 重复建设
- AP-07 [应用] 控制面空心
- AP-08 [应用] 纯 ReAct 在线
- AP-09 [应用] 无 verify 闸门
- AP-10 [应用] Coordinator 过多
- AP-11 [应用] 护栏后置
- AP-12 [应用] 工具无 schema
- AP-13 [数据] checkpoint 在 Pod
- AP-14 [数据] 向量无租户
- AP-15 [数据] artifact 塞 PG
- AP-16 [数据] 无 version_pin
- AP-17 [数据] audit 缺失
- AP-18 [数据] eval 无版本
- AP-19 [部署] 单 AZ
- AP-20 [部署] 无 HPA
- AP-21 [部署] staging 无 gate
- AP-22 [部署] GPU 无利用率监控
- AP-23 [部署] LLM 与 Runtime 同扩
- AP-24 [部署] 无降级开关
- AP-25 [安全] prompt 防火墙
- AP-26 [安全] 工具过度授权
- AP-27 [安全] 无注入检测
- AP-28 [安全] audit 可篡改
- AP-29 [安全] 密钥进 prompt
- AP-30 [安全] 跨租户 session
- AP-31 [集成] 直连数据库
- AP-32 [集成] 无 Outbox
- AP-33 [集成] Agent 协调 Saga
- AP-34 [集成] 无防腐层
- AP-35 [集成] Webhook 无签名
- AP-36 [集成] 批处理走 Chat
- AP-37 [演进] 跳阶段 Multi-Agent
- AP-38 [演进] 无 eval 扩量
- AP-39 [演进] 双编排打架
- AP-40 [演进] 无兼容期
- AP-41 [演进] 技术债无 ADR
- AP-42 [演进] Mesh 前无 trace
23. 附录 J:容量估算公式(Agent 专用)
峰值 Agent QPS = 总峰值 QPS × Agent 流量占比
Token/s ≈ QPS × avg_tokens_per_task / avg_task_duration_s
$/hour ≈ Token/s × 3600 × blended_price_per_1k / 1000
Runtime 副本 ≈ ceil(峰值并发任务 / 每 Pod 并发任务数)
GPU 卡数 ≈ ceil(峰值 Token/s / 每卡 Token/s) # 见 07 Serving
Checkpoint 写 QPS ≈ 峰值任务 QPS × avg_steps × checkpoint_every_step
PG 连接池 ≥ Runtime 副本 × 每副本连接数
面试要带一个你自己的估算例子(替换数字即可)。
官方文档与源码(一级依据)
AI Engineering · 正文机制应来自下方 官方文档(L1) 与 官方源码仓库(L2);
禁止用教程站/博客充当机制依据。本章 QPS/延迟/STAR 为面试示意。
写作规范:docs/official-sources-registry.md §0
L1 · 官方文档
L2 · 官方源码
L3 · 论文 / 开放规范
更多推荐

所有评论(0)