15 系统设计题

第一部分 速记页

第二部分 易混对照

第三部分 面试口述稿

3.1 “系统设计题你一般怎么答？”

我按八步来。

第一步先问清楚需求，不急着画图。用户是谁、每天多少量、对准确率和延迟的要求、出错的代价有多大、有哪些现有系统要对接、数据有没有权限区分。还要判断这个需求是不是真的需要 Agent，如果流程是固定的，用工作流更稳更便宜。

第二步说核心流程，一次请求从进来到返回经过哪几步。第三步画架构图，把前端、后端、模型、检索、工具、存储画出来。第四步讲数据和存储，存什么、怎么更新。第五步讲工具和权限，Agent 能调哪些工具、每个工具的权限边界、哪些操作要人确认。

后三步是很多人会漏的：评测，怎么知道系统做得好、改动之后没变差；成本和延迟，做一个粗略估算；风险和兜底，幻觉、注入、越权、下游故障分别怎么处理。

时间不够的话，前五步讲主干，后三步每步至少说两句，因为这三步最能体现做过工程。

3.2 “设计一个企业内部知识库问答系统”

我先会问几个问题：文档有多少、什么格式、多久更新一次；员工对不同文档的权限是否不同；回答需不需要给出处；能不能接受”不知道”。假设是几十万份文档、PDF 和网页为主、每天有更新、不同部门权限不同、必须给出处。

核心流程分离线和在线两条。离线：文档解析、清洗、按结构切片，每个片段带上文档标题、来源、权限标签，做向量化存进向量库，同时建关键词索引；文档变更时按文档 ID 增量更新。在线：用户提问，先按用户身份拿到可访问的权限范围，检索时带上权限过滤，向量和关键词混合检索，融合后重排取前几个片段，拼进提示词让模型回答，要求每个结论标注片段编号，最后程序检查引用的编号确实存在。

最重要的一点是权限要在检索层过滤，没权限的文档根本不能进上下文，不能靠提示词让模型别说。

评测上，先从真实提问里收集一两百个问题，标注正确的文档片段和参考答案，分别评检索的召回率和回答的忠实度。成本上，一次问答输入三四千 token，按便宜模型算一次不到一分钱人民币。风险主要是幻觉和过期文档，兜底是允许拒答、回答带出处和文档更新时间。

3.3 “设计一个电商客服 Agent”

先问：处理哪些问题，查物流、退换货、改地址还是全都要；Agent 能不能直接执行退款，还是只能提交申请；每天多少会话；转人工的条件是什么。假设要处理查订单、查物流、退货申请，退款金额小的可以自动执行。

这个场景和知识库问答最大的区别是有写操作。工具设计上，查询类工具只读，比如查订单、查物流；写操作工具比如提交退货、退款，参数由后端再校验一遍：订单是不是这个用户的、是否在退货期内、金额是否超过阈值。超过阈值的走人工确认。退款要带幂等键，网络重试不能退两次。

身份上，工具一律用当前登录用户的身份去调业务系统，模型给的订单号只是参数，归属由后端校验，防止用户通过对话查别人的订单。

转人工是必须的兜底：用户明确要求、情绪激动、连续几轮没解决、涉及投诉或高金额时转人工，并把对话摘要一起交过去。

评测上客服特别要看稳定性，τ-bench 论文里就发现客服场景单次成功率不到一半的模型，连续 8 次都成功的比例更低，所以要看 pass^k，而且要模拟多轮对话。线上看完成率、转人工率、用户满意度。

3.4 “设计一个 Coding Agent”

我项目其实就是这一类的简化版，所以我会结合它讲。

先问：是在用户本地跑还是云端跑；改哪些仓库；产出是直接提交还是给人审核；有没有测试。假设是云端跑、针对公司内部仓库、产出是一个待审核的合并请求。

核心是三件事。第一是沙箱：Agent 要执行命令、跑测试，必须在隔离的容器里，只挂载这个仓库、默认断网、有资源和时间上限。我项目就是没做容器，只做了工具层检查，结果评测里发现模型能通过写构建脚本绕过路径检查。

第二是用程序验证结果，而不是信模型说”改好了”。跑已有测试、跑新写的测试、跑静态检查，全部通过才算完成。我项目的验收就是独立重新构建并检查产物架构，还修过两次验收自身的 bug。

第三是人审核：产出是 diff，给人看，Agent 不能直接合入主分支。

另外工具接口要为 Agent 专门设计，比如读文件支持分页、命令输出截断但保留退出码、编辑文件用明确的替换而不是整个重写。我项目里读文件原来只保留末尾 100 行，模型为了看前半部分绕了很多弯路，改成分页后这类绕路就没有了。

3.5 “设计一个深度调研 Agent”

这是多 Agent 比较适合的场景，因为调研可以按方向拆开并行做。

先问：调研报告给谁看、要多长、能花多少时间和钱、信息源是公开网页还是内部资料。

架构用主管-工人：主 Agent 先分析问题、拆成几个互不依赖的方向，给每个子 Agent 写清楚目标、输出格式、可用的搜索工具和边界；子 Agent 并行搜索、阅读，只把带出处的要点交回来；主 Agent 汇总写报告；最后有一步专门核对引用，检查每个结论引用的来源确实支持这个结论。

关键设计是预算控制：按问题复杂度决定派几个子 Agent、每个最多多少次搜索，Anthropic 公开的研究系统里多 Agent 的 token 用量大约是普通对话的 15 倍，不控制成本很容易失控。还有网页内容是不可信的，要防间接注入，子 Agent 只有搜索和读取工具，不能对外发送任何东西。

评测上可以用模型当裁判，按准确性、引用质量、完整性打分，但要先用人工标注校准。

第四部分 逐个详解

4.1 答题框架（八步）

flowchart TD
    S1["① 澄清需求<br/>用户 量 准确率 延迟 出错代价<br/>要不要 Agent"] --> S2["② 核心流程<br/>一次请求经过哪几步"]
    S2 --> S3["③ 架构图<br/>前端 后端 模型 检索 工具 存储"]
    S3 --> S4["④ 数据与存储<br/>存什么 怎么更新 怎么查"]
    S4 --> S5["⑤ 工具与权限<br/>工具清单 权限边界 人工确认"]
    S5 --> S6["⑥ 评测<br/>评测集 分层 线上指标"]
    S6 --> S7["⑦ 成本与延迟<br/>粗略估算 优化手段"]
    S7 --> S8["⑧ 风险与兜底<br/>幻觉 注入 越权 故障"]

每一步该问、该说什么：

第一步里最重要的一个判断：要不要 Agent。 05 篇引用过 Anthropic 的建议，先用最简单的方案，只有在确实需要时才增加复杂度。

很多”设计一个 XX Agent”的题，核心部分其实用工作流就够了。主动指出这一点是加分项。

时间分配：一道题一般 30 到 45 分钟。前五步是主干，占大部分时间；但后三步每步至少说两三句，因为评测、成本、风险最能区分”做过项目”和”看过文章”。

4.2 快速估算：成本和流量

面试时不需要精确，但要能在一两分钟内说出数量级，并说清楚假设。

动手实验：保存为 estimate.py。价格用写这篇时核对的 DeepSeek deepseek-flash 非高峰价（每百万 token：未命中 0.15 美元、命中 0.003 美元、输出 0.6 美元），价格会变，只作演示。

PRICE_MISS, PRICE_HIT, PRICE_OUT = 0.15, 0.003, 0.6


def call_cost(inp, out, cached):
    return ((inp - cached) * PRICE_MISS + cached * PRICE_HIT + out * PRICE_OUT) / 1e6


def rag_qa(users, per_user, system=800, chunks=5, chunk=400, history=600, question=60, out=350):
    inp = system + chunks * chunk + history + question
    per_query = call_cost(inp, out, cached=system)
    queries = users * per_user
    return queries, inp, per_query, per_query * queries


def agent_task(steps, system=2500, per_step_in=900, out=150, hit_ratio=0.8):
    total, context = 0.0, system
    for _ in range(steps):
        total += call_cost(context, out, cached=int(context * hit_ratio))
        context += out + per_step_in
    return context, total


queries, inp, per_q, day = rag_qa(users=2000, per_user=8)
peak_qps = queries * 0.3 / 3600
print(f"知识库问答：每天 {queries:,} 次，单次输入 {inp:,} token，单次 ${per_q:.5f}，每天 ${day:.2f}，高峰约 {peak_qps:.1f} QPS")

for steps in (6, 20, 40):
    ctx, cost = agent_task(steps)
    ctx0, cost0 = agent_task(steps, hit_ratio=0)
    print(f"Agent {steps:>2} 步：最后上下文 {ctx:>6,} token，缓存命中 80% ${cost:.4f}，无缓存 ${cost0:.4f}")

实际输出（Python 3.14，只用标准库）：

知识库问答：每天 16,000 次，单次输入 3,460 token，单次 $0.00061，每天 $9.78，高峰约 1.3 QPS
Agent  6 步：最后上下文  8,800 token，缓存命中 80% $0.0015，无缓存 $0.0052
Agent 20 步：最后上下文 23,500 token，缓存命中 80% $0.0099，无缓存 $0.0392
Agent 40 步：最后上下文 44,500 token，缓存命中 80% $0.0334，无缓存 $0.1414

逐段讲。

• PRICE_MISS, PRICE_HIT, PRICE_OUT = 0.15, 0.003, 0.6：一行给三个变量赋值，右边的三个值按顺序对应左边三个名字，这叫多重赋值（本质是元组拆包）
• call_cost：10 篇讲过的成本公式，除以 1e6 是因为价格按每百万 token 计。1e6 是科学计数法，等于 1000000.0
• rag_qa 的默认参数就是假设：系统提示词 800、检索 5 个片段每个 400、对话历史 600、问题 60、回答 350 token。只有系统提示词能稳定命中缓存，所以 cached=system
• peak_qps = queries * 0.3 / 3600：假设一天里最忙的那一小时占全天 30% 的请求，除以 3600 秒得到每秒请求数
• agent_task：每一步把当前上下文全部发出，模型输出 150 token、工具结果 900 token 加回上下文。hit_ratio=0.8 假设 80% 的输入命中缓存（前缀和上一步相同的部分）
• int(context * hit_ratio)：int() 把小数截成整数

看结果，面试时能说的几句话：

1. 知识库问答很便宜：2000 个员工每人每天问 8 次，一天不到 10 美元，高峰 1 点几 QPS。瓶颈通常不在成本，而在解析质量和检索准确率
2. Agent 的成本随步数加速增长：6 步到 40 步，步数约 6.7 倍，无缓存成本约 27 倍（0.0052 → 0.1414）。因为每步都重发越来越长的历史
3. 缓存影响很大：40 步时有缓存 0.033 美元，无缓存 0.141 美元，差 4 倍多。所以系统提示词、工具定义要放前面保持稳定（06 篇）
4. 这些假设要用真实数据校准。拿我项目对照：LangGraph 对比那组数据里，手写版平均每次运行输入 14.4 万 token，10 个项目平均约 13.6 步（简单中等 8 个平均 10.8 步、困难 2 个平均 25 步）；按这个模型算 14 步的输入合计是 130,550 token，数量级对得上。但项目没记录缓存命中，80% 命中率只是假设

QPS 和并发数的换算：Agent 请求时间长，并发数远大于 QPS。

同时在跑的任务数 ≈ 每秒新任务数 × 平均任务时长

每秒 1 个新任务、每个跑 60 秒，同时就有约 60 个任务在跑。这决定了工作进程数、模型 API 的并发限额、数据库连接数。这个关系在排队论里叫利特尔法则（Little’s Law）。

它的来历。 这个公式本身很早就有人在用：1954 年 Alan Cobham 的论文直接拿它当已知结论，1958 年 Philip M. Morse 把它写成 L = λW，还请读者找反例。问题是没人证明过它在什么条件下一定成立。1961 年运筹学学者 John D. C. Little 在《运筹学》（Operations Research）期刊上发表了 A Proof for the Queuing Formula: L = λW，给出了第一个严格证明，公式从此用他的名字命名。三个字母对应的就是上面那行：L 是系统里平均同时有多少个任务，λ 是平均每秒进来多少个，W 是每个平均待多久。它厉害的地方在于几乎不挑前提，不管任务是怎么到达的、每个耗时怎么分布，只要长期看进出平衡就成立，所以估算 Agent 并发时可以放心拿来用。

自己改一改：

1. 把知识库问答的 chunks 从 5 改成 20（检索更多片段），看单次成本变化
2. 把 agent_task 的 per_step_in 改成 3000（工具返回很长），看 40 步的成本
3. 算一下：每秒 2 个新 Agent 任务、平均 90 秒，需要同时支持多少个任务

4.3 题一：企业内部知识库问答

① 澄清需求（问完之后说出你的假设）：

判断要不要 Agent：大部分问题是”检索 → 生成”两步，工作流就够了。只有”对比三份制度的差异”这类需要多次检索的复杂问题，才考虑让模型自己决定查几次。

② 核心流程和 ③ 架构：

flowchart TB
    subgraph 离线
        SRC[文档源<br/>网盘 Wiki 系统] --> PARSE[解析 清洗]
        PARSE --> CHUNK[按结构切片<br/>带标题 来源 权限 更新时间]
        CHUNK --> EMB[向量化]
        EMB --> VDB[(向量索引)]
        CHUNK --> KW[(关键词索引)]
        SRC -.->|变更事件| INC[增量更新<br/>按文档 ID 删旧片段 写新片段]
        INC --> VDB
        INC --> KW
    end
    subgraph 在线
        U[员工提问] --> AUTH[身份 → 可访问的权限范围]
        AUTH --> RW[查询改写<br/>结合对话历史补全指代]
        RW --> RET[混合检索<br/>带权限过滤]
        VDB --> RET
        KW --> RET
        RET --> RR[融合 + 重排<br/>取前 5]
        RR --> GEN[生成<br/>要求标注片段编号]
        GEN --> CHK[引用校验<br/>编号存在 片段支持结论]
        CHK --> OUT[流式返回<br/>附出处和更新时间]
    end

④ 数据与存储：

关键设计点（面试时重点讲）：

1. 权限在检索层过滤。片段带权限标签，检索时只在用户可访问的范围内查。不能先全量检索、再让模型”不要说出没权限的内容”，资料一旦进了上下文就可能泄露（08、11 篇；OWASP LLM08 向量和嵌入弱点）
2. 切片带上下文。片段脱离原文会丢失”在讲哪份文档哪一章”，切片时把文档标题、章节路径加到片段前面。Anthropic 的 Contextual Retrieval 实验里，给片段补上下文加上下文化的 BM25，检索失败率降低 49%，再加重排降低 67%（08 篇）
3. 混合检索。员工会搜制度编号、产品型号这类精确词，纯向量检索容易漏，要加关键词检索
4. 增量更新。按文档 ID 管理片段，文档修改时删掉旧片段写入新的；文档删除时片段也要删，否则会答出已废止的制度
5. 引用和拒答。提示词要求只根据资料回答并标注编号；程序检查编号存在；检索分数都很低时直接回答”没找到相关资料”

⑥ 评测：

⑦ 成本与延迟：按 4.2 节估算，一天不到 10 美元。延迟主要是检索（向量检索几十毫秒，重排可能上百毫秒到一秒以上，我项目实测 bge-reranker 每条查询 1.1 秒）加模型首 token 时间，流式输出改善体感。

⑧ 风险与兜底：

追问：

4.4 题二：电商客服 Agent

① 澄清需求：

判断要不要 Agent：用户的问题五花八门，需要多轮对话、按情况调不同的查询和操作工具，适合 Agent。但每一类业务流程（比如退货）内部的规则应该由后端代码保证，而不是靠模型记住。

② 核心流程和 ③ 架构：

flowchart LR
    U[用户] --> GW[对话网关<br/>登录身份]
    GW --> AG[客服 Agent<br/>多轮状态]
    AG -->|只读| T1[查订单]
    AG -->|只读| T2[查物流]
    AG -->|只读| T3[知识库 FAQ]
    AG -->|写 带幂等键| T4[提交退货]
    AG -->|写 超阈值需确认| T5[退款]
    AG --> T6[转人工<br/>带对话摘要]
    T1 & T2 & T4 & T5 --> BIZ[业务系统<br/>以用户身份鉴权]
    T5 -.->|金额超阈值| HUM[人工审核台]
    T6 --> HUM
    AG --> LOG[(对话 轨迹 审计)]

关键设计点：

1. 身份和鉴权在后端。工具调用业务系统时带的是当前登录用户的身份，模型给的订单号只是参数。后端检查订单归属，防止”帮我查一下订单 12345”查到别人的订单
2. 业务规则在代码里。退货期限、退款金额上限、商品是否支持退货，由后端校验。模型可以解释规则，但不能决定规则
3. 写操作幂等。退款请求带幂等键（比如”会话 ID + 订单号 + 操作类型”），网络超时重试不会退两次（07 篇）
4. 人工确认和转人工。超阈值的退款挂起，等人工在审核台确认；转人工时把对话摘要和已查到的订单信息一起交过去，用户不用重复描述
5. 状态机约束对话。退货流程有明确步骤（确认订单 → 确认原因 → 确认退货方式 → 提交），可以把当前步骤存在会话状态里，只开放这一步需要的工具，减少模型乱调

退款的时序：

sequenceDiagram
    participant U as 用户
    participant A as 客服 Agent
    participant T as 退款工具
    participant B as 业务系统
    participant H as 人工审核
    U->>A: 耳机坏了，要退款
    A->>T: refund(order_id, reason)
    T->>B: 以用户身份查订单
    B-->>T: 订单属于该用户，金额 299 元
    T->>T: 超过 100 元阈值
    T->>H: 创建审核单（幂等键）
    T-->>A: 已提交人工审核
    A-->>U: 已提交，预计 24 小时内处理
    H->>B: 审核通过，执行退款（同一幂等键）

⑥ 评测：

• 模拟多轮对话：用另一个模型扮演用户，按剧本提出问题、中途改主意、提供错误信息。τ-bench 就是这样测的，模拟用户、工具和业务规则
• 看 pass^k：τ-bench 发现当时最强的 GPT-4o 在零售场景单次成功率不到 50%，连续 8 次都成功的比例不到 25%。客服每次都要做对，要看稳定性（09 篇）
• 按结果检查：对话结束后检查数据库状态，比如退货单是否正确创建、有没有错误的退款
• 安全用例：查别人的订单、诱导超额退款、提示词注入，必须全部拦住
• 线上：问题解决率、转人工率、平均轮数、用户满意度、错误退款金额

⑦ 成本与延迟：每个会话平均 6 到 10 步，按 4.2 节估算每个会话不到 1 美分，每天 5 万会话几百美元以内。延迟要求高，每一轮要在几秒内回复，简单的 FAQ 可以不走 Agent 直接检索回答。

⑧ 风险与兜底：

追问：

4.5 题三：Coding Agent

① 澄清需求：

② 核心流程和 ③ 架构：

flowchart TB
    TICKET[工单] --> ORCH[任务调度]
    ORCH --> SB[沙箱容器<br/>只挂载仓库副本<br/>网络只放行包仓库<br/>CPU 内存 时长上限]
    subgraph SB2[沙箱内]
        AG[Agent 循环] --> TOOLS[工具<br/>搜索代码 分页读文件<br/>精确替换编辑 执行命令]
        TOOLS --> REPO[(仓库副本)]
    end
    SB --> SB2
    AG --> VERIFY[程序验收<br/>编译 已有测试 新测试 静态检查]
    VERIFY -->|失败| AG
    VERIFY -->|通过| PR[生成 diff<br/>创建合并请求]
    PR --> REVIEW[人工审核]
    AG --> TRACE[(轨迹 审计)]

关键设计点：

1. 沙箱是边界，工具层检查只是辅助。11 篇讲过，构建工具和测试框架本身就能执行任意代码，命令白名单挡不住。容器只挂载仓库副本、网络只放行需要的包仓库、不传入宿主机的环境变量和凭据
2. 用程序验证，不信模型自述。完成的判据是编译通过、测试通过、静态检查通过，由调度程序在 Agent 结束后独立再跑一遍
3. 防止钻验收的空子。模型可能删掉失败的测试、把断言改成永远成立。验收时要检查 diff 里有没有修改测试文件，修改了要特别标注给审核人。我项目遇到过类似情况：有一次 Agent 修改了项目的 CMakeLists.txt，加了一个示例目标来满足”必须有编译产物”的验收
4. 为 Agent 设计工具接口。SWE-agent 论文（2405.15793）提出了”Agent-计算机接口”的概念，认为给 Agent 专门设计的命令和反馈格式能明显提升效果。实践上：搜索代码的工具返回文件和行号；读文件分页；编辑用精确替换；命令输出截断但保留退出码和完整日志的位置
5. 人审核 diff。Agent 不能直接合入主分支；合并请求里附上 Agent 的思路摘要和验证结果

我项目对照（这道题我可以用自己的项目讲很具体的例子）：

⑥ 评测：用历史上真实修过的 bug 构造任务（有修复前的代码、修复后通过的测试），类似 SWE-bench 的做法；评分器就是跑测试；每个任务多跑几次看稳定性；另外看合并请求被审核通过的比例和审核时修改的量。

⑦ 成本：编码任务步数多、每步读的文件长，单个任务几十万 token 很常见。我项目单次运行平均输入十几万 token。要控制：步数上限、读文件分页、历史压缩、搜索工具返回摘要而不是全文。

⑧ 风险与兜底：

追问：

4.6 题四：深度调研 Agent

① 澄清需求：

② 核心流程和 ③ 架构：

flowchart TD
    Q[调研问题] --> LEAD[主 Agent<br/>分析问题 拆方向<br/>按复杂度定预算]
    LEAD -->|方向 1 任务说明| S1[子 Agent 1<br/>网页搜索 读取]
    LEAD -->|方向 2| S2[子 Agent 2<br/>网页搜索 读取]
    LEAD -->|方向 3| S3[子 Agent 3<br/>内部资料检索]
    S1 -->|要点 + 出处| LEAD
    S2 -->|要点 + 出处| LEAD
    S3 -->|要点 + 出处| LEAD
    LEAD --> DRAFT[撰写报告]
    DRAFT --> CITE[引用核对<br/>每个结论对应的原文<br/>是否真的支持它]
    CITE -->|不支持| DRAFT
    CITE --> OUT[报告 + 出处列表]

关键设计点：

1. 主管-工人，并行查。调研可以按方向拆开，子 Agent 之间几乎不需要协调，是 13 篇里说的适合多 Agent 的典型场景
2. 任务说明写全。每个子 Agent 的任务要写清目标、输出格式、该用哪些工具和信息源、边界，否则会重复搜索或者漏掉（Anthropic 多 Agent 研究系统的经验）
3. 按复杂度控制预算。简单问题一个子 Agent 几次搜索就够；复杂问题多派几个。每个子 Agent 有搜索次数和 token 上限。Anthropic 的数据是多 Agent 系统 token 约为普通对话的 15 倍
4. 引用核对。子 Agent 交回要点时必须附原文片段和链接；报告写完后，逐条检查结论和原文是否一致，不一致的删除或改写。这一步可以用模型做，但要保留原文供人核查
5. 防注入。网页内容是不可信的，子 Agent 只有搜索和读取工具，没有任何对外发送或写入的能力，致命三要素里缺了”对外通信”。内部资料检索要按用户权限过滤

⑥ 评测：结果是开放式文本，很难用程序判对错。可以：用模型当裁判按事实准确性、引用是否支持结论、完整性、来源质量打分（先用人工标注校准，09 篇）；准备一批有公认答案的问题检查关键事实；统计引用核对失败的比例。

⑦ 成本与延迟：成本最高的一类，要设单份报告上限；并行显著缩短时间，Anthropic 提到并行工具调用让复杂查询的研究时间最多缩短 90%。

⑧ 风险与兜底：

追问：

4.7 几个通用追问怎么接

4.8 用这个框架讲我自己的项目

面试官常说”你就拿你的项目当设计题讲一遍”。CrossBuild Agent 按八步：

第⑧步主动说”未处理”的部分，比只讲做到的更有说服力。

第五部分 对照项目

第六部分 追问清单

第七部分 闭卷自测

1. 系统设计题的八步框架是什么？哪三步最容易被漏掉，为什么它们重要？

2. 第一步澄清需求至少要问哪些问题？还要做一个什么判断？

3. 实验里 Agent 步数从 6 到 40，无缓存成本增长了多少倍？为什么远超步数的倍数？缓存有多大影响？

4. 每秒 2 个新 Agent 任务、平均每个 90 秒，同时大约有多少个任务在跑？这影响哪些资源规划？

5. 企业知识库问答为什么要在检索层做权限过滤？只在提示词里要求模型不说有什么问题？

6. 知识库文档修改或删除时，索引怎么处理？不处理会怎样？

7. 客服 Agent 的退款工具要做哪几层保护？

8. 为什么客服 Agent 的评测要看 pass^k 并模拟多轮对话？τ-bench 的数据说明了什么？

9. Coding Agent 设计里最关键的三件事是什么？分别用我项目的经验说明。

10. 模型可能怎样”钻验收的空子”？怎么防？

11. 深度调研 Agent 为什么适合多 Agent？怎么控制成本、怎么保证结论可靠？

12. 面试官问”流量涨 10 倍”和”模型服务挂了”，分别怎么答？

延伸阅读

1. Anthropic：Building effective agents（2024-12）— 什么时候用工作流、什么时候用 Agent
2. Anthropic：Contextual Retrieval（2024-09）— 知识库检索的具体改进和数据
3. τ-bench（2024）— 客服类 Agent 的评测方法和 pass^k
4. SWE-agent（2024）— 为 Coding Agent 设计 Agent-计算机接口
5. Anthropic：How we built our multi-agent research system（2025-06）— 深度调研 Agent 的完整案例
6. OWASP GenAI LLM Top 10 2026（2026-08）和 Top 10 for Agentic Applications — 设计时逐条对照风险，11 篇 4.2 节有 2026 版的中文对照表

下一篇：16 项目怎么讲——把整个系列落到你自己的项目上，准备 1 分钟、3 分钟、10 分钟三个版本。