通用智能体平台

典型题：设计一个企业内部 Agent 平台，支持多个业务创建 Agent、配置工具、接入知识库、查看 trace 和评估结果。

面试官真正想看什么

平台接入一个会发邮件的工具后，租户隔离、版本发布和审批马上变成真实问题。一个好平台不是工具越多越好，而是能知道谁在什么版本、什么权限下调用了什么，并能快速禁用。

• 你能不能把 Agent 从 demo 抽象成平台能力。
• 你知道平台化会带来权限、配置、版本、观测和评估问题。
• 你不会一上来做“大而全”，而是从最小闭环扩展。

先问清楚

Q1：设计 Agent 平台前先问什么？

参考答案

我会先问：

• 平台用户是谁：研发、运营、客服、数据团队还是业务部门。
• Agent 类型有哪些：客服、调研、知识库、代码审查、数据分析。
• 是否需要低代码配置。
• 是否支持自定义工具。
• 是否需要多租户和权限隔离。
• 是否需要统一评估和发布流程。

最小架构

核心模块

Q2：Agent 平台最小版本包含什么？

参考答案

最小版本包含：

• Agent 配置：prompt、模型、工具、知识库、预算。
• 工具注册：工具 schema、权限、调用地址。
• 运行时：tool loop、状态、最大轮数。
• 日志：trace、usage、cost、error。
• 测试入口：用样本跑 Agent。

不要一开始就做复杂 marketplace、插件生态和可视化大屏。先把一个 Agent 跑稳。

Q3：Agent 配置怎么版本化？

参考答案

每次改 prompt、模型、工具列表、知识库版本、guardrails 都要生成配置版本。运行 trace 记录配置版本，方便回放和回滚。

没有版本化，线上出了问题就不知道是 prompt 改了、模型换了还是工具变了。

Q4：工具注册中心怎么设计？

参考答案

工具注册中心要保存：

• 工具名。
• 描述。
• 参数 schema。
• 输出 schema。
• 权限要求。
• 超时和重试策略。
• 是否危险动作。
• owner。

工具不是只给模型看的文本，也是一种受控执行能力。

Q5：知识库怎么接入 Agent？

参考答案

平台可以让 Agent 绑定一个或多个知识库。查询时按用户和 Agent 权限过滤，再做检索、rerank 和证据裁剪。

知识库必须有版本、权限和更新状态。否则 Agent 可能引用旧知识或无权限资料。

Q6：状态和记忆怎么做平台化？

参考答案

状态分为任务状态和长期记忆：

• 任务状态：当前目标、阶段、工具结果、错误、预算。
• 长期记忆：用户偏好、项目背景、历史摘要。

平台要允许业务选择是否开启长期记忆，并提供查看、删除和失效机制。

Q7：如何防止用户配置出危险 Agent？

参考答案

平台要有 guardrails：

• 高风险工具默认禁用。
• 写操作必须确认。
• 工具权限审批。
• prompt injection 检测。
• 输出安全检查。
• 预算限制。

不能让业务方随便把“删除数据”工具暴露给任意 Agent。

发布与评估

Q8：Agent 发布流程怎么设计？

参考答案

我会设计成：

1. 草稿配置。
2. 本地样本测试。
3. eval 集回归。
4. 小流量灰度。
5. 观察 trace、成本、安全。
6. 正式发布。
7. 可回滚。

Agent 配置发布应该像代码发布一样可回滚、可追踪。

Q9：平台级 eval 怎么设计？

参考答案

平台提供通用指标：

• 任务成功率。
• 工具调用正确率。
• 引用准确率。
• 无答案识别率。
• 平均成本。
• P95 延迟。
• 安全违规率。

不同 Agent 还可以有业务指标，比如客服解决率、调研引用覆盖率、代码 review 采纳率。

Q10：平台如何支持多模型？

参考答案

通过模型网关统一接入。Agent 配置选择默认模型，也可以按步骤路由：小模型分类，大模型推理，embedding 模型检索，rerank 模型排序。

Q11：这个平台最难的点是什么？

参考答案

最难的是治理。Agent 平台一旦开放给多个业务，就会出现工具权限、配置漂移、成本失控、评估缺失、知识库版本不一致的问题。

30 秒收口

我会先做一个支持配置、工具、知识库、运行时、trace 和 eval 的最小 Agent 平台。
核心不是让业务随便搭 Agent，而是让 Agent 的工具、权限、版本、成本和评估都可治理。

本题常见扣分点

• 一上来画大而全平台。
• 不讲版本和回滚。
• 不讲工具权限。
• 不讲 eval。
• 不讲多租户和预算。

深挖追问：平台化之后如何真正可运营

Q12：多租户应该隔离哪些东西，怎样避免“逻辑上隔离、实际上串数据”？

参考答案

我会先明确租户边界：Agent 定义、配置版本、工具授权、知识库、运行任务、长期记忆、trace、预算和发布环境都属于租户资源。所有资源都有不可变的 tenant_id，服务端从登录身份或服务身份中得到租户，不接受调用方在请求体中自行指定一个更高权限的租户。数据库查询、对象存储路径、缓存 key、消息队列 topic 和向量检索过滤都必须带租户条件，不能只在前端隐藏数据。

隔离可以分层做。一般 SaaS 场景使用共享数据库加行级权限和强制 tenant filter；对高敏感客户，可以使用独立 schema、独立数据库甚至独立运行集群。无论哪一层，平台都要做跨租户访问的自动化测试：用租户 A 的 token 请求租户 B 的 Agent、文件、记忆和 trace，必须得到 404 或 403，并检查缓存和错误日志没有泄露对象名称。

租户内部还要有成员、角色和资源级权限，例如 owner、builder、viewer、operator、auditor。一个用户可以查看某个 Agent 的运行记录，却不一定能看到 prompt 原文或重放它；生产发布权限和配置编辑权限也应分离。管理员跨租户排查必须有临时授权、原因、有效期和审计记录。

替代方案何时使用

单企业内部平台可以先用共享库加严格租户字段和 RBAC；当客户有数据驻留、专属密钥或强隔离合同要求时，再为该租户切换到独立资源，不要一开始所有租户都物理隔离导致运维成本过高。

常见扣分点

• 只说“每个租户一个 namespace”，却不覆盖缓存、trace、队列和长期记忆。
• 只在前端做权限控制。
• 把平台管理员默认为无限制超级用户，没有审计和时效。

Q13：Agent 的配置版本应该包含什么，如何保证一次运行可复现？

参考答案

一个可运行的 Agent 版本不是单独一段 system prompt，而是一个不可变 manifest，至少包含：模型和参数、系统提示词、工具列表及 schema、工具授权策略、知识库索引版本、记忆策略、输出 schema、guardrails 版本、路由策略、预算、运行时图版本以及依赖的模板或代码版本。配置中心保存内容的 hash 和父版本，修改产生新版本，不能原地覆盖已经被生产任务引用的版本。

运行时创建 run 时把完整 agent_version_id 固定下来，并把实际路由模型、工具版本、知识库版本、提示词模板版本、输入摘要和随机性参数写入 trace。这样同一个任务即使后来 Agent 发布了新版本，也不会在重试中悄悄变成另一套逻辑。涉及外部数据的重放要说明数据快照或抓取时间，因为模型版本固定也不代表网页和日历内容固定。

版本状态可以是 DRAFT -> TESTING -> APPROVED -> CANARY -> ACTIVE -> DEPRECATED -> RETIRED。已被运行引用的版本不能删除，只能停止新任务使用；历史 trace 仍能关联到它。配置提交时做 schema 校验、工具权限校验、循环检测、预算上限检查和敏感 prompt 检查，减少把非法配置带到运行时。

替代方案何时使用

小型内部原型可以先用 Git 管理 YAML manifest；多人在线编辑、审批、运行回放和租户权限较多时，需要配置中心提供版本、diff、锁定和发布记录，Git 可以作为底层存档而不是唯一运行时数据库。

常见扣分点

• 只给 prompt 加版本号，没有锁定模型、工具和知识库版本。
• 重试时读取“当前最新配置”，导致同一任务前后行为不一致。
• 直接删除旧版本，历史 trace 无法解释。

Q14：平台的核心 API 和运行状态怎样设计？

参考答案

我会把控制面和数据面分开。控制面负责 POST /agents 创建草稿、POST /agents/{id}/versions 保存版本、POST /versions/{id}/validate 校验、POST /versions/{id}/deploy 发布、GET /runs/{id} 查询运行；数据面负责 POST /runs 创建一次执行、GET /runs/{id}/events 流式读取事件、POST /runs/{id}/cancel 取消任务，以及受策略保护的 POST /runs/{id}/approve 执行确认动作。

运行状态至少包括 QUEUED、RUNNING、WAITING_TOOL、WAITING_USER、PAUSED、SUCCEEDED、FAILED、CANCELLED、BUDGET_EXHAUSTED。状态迁移由服务端校验，例如 WAITING_USER 不能被普通重试接口直接改成 SUCCEEDED，而外部动作确认必须绑定具体的 approval_id 和草稿 hash。事件采用追加写入：run.started、model.called、tool.requested、tool.completed、approval.requested、approval.granted、run.failed。

运行状态和事件的关系要清楚：事件是审计和恢复依据，当前状态是查询优化视图。Worker 处理事件时使用租约和幂等键；进程崩溃后，调度器根据未完成步骤和最近 checkpoint 重新派发，不依赖内存中的 Agent 对象。流式输出只展示已产生的事件，最终结果仍以服务端持久化 artifact 为准。

替代方案何时使用

纯同步、几秒内完成的分类 Agent 可以只返回一次响应；长时间检索、工具调用、审批和批处理任务必须采用异步 run 加事件流，否则请求超时后无法知道任务是否已经执行。

常见扣分点

• 只有一个 status=running 字段，没有等待人工、预算耗尽和取消语义。
• 把状态全放在 Redis 或 Worker 内存，重启就丢。
• 允许客户端任意提交状态，绕过审批和权限。

Q15：平台的容量和延迟目标怎样估算？

参考答案

我会先把平台负载拆成控制面请求和运行时步骤。假设有 2,000 个活跃 Agent、每天 50,000 次 run，高峰 10 倍；平均每次 run 4 次模型调用、2 次工具调用，模型调用平均 2 秒，工具平均 300 毫秒。模型调用往往是主要瓶颈，不能按“run QPS”简单估算 Worker 数，而要按并发模型请求、供应商 TPM/RPM、工具连接池和队列等待分别做容量规划。

用户体验也要拆 SLO：提交任务接口 P95 小于 300 毫秒；流式首事件 P95 小于 1 秒；短问答完成 P95 小于 10 秒；长任务可以异步完成并提供进度、预计剩余步骤和取消能力。平台运行时设置每租户并发上限、每 Agent 并发上限和全局模型并发上限，长任务使用持久队列，避免某个批量 Agent 把交互式任务挤掉。

容量测试至少覆盖：空闲工具、慢工具、模型 429、长上下文、并发审批、消息重复和 Worker 崩溃。监控重点是队列等待、步骤耗时、外部依赖耗时、活跃 run、每租户 token、checkpoint 存储增长和 P95/P99，而不是只看 API 服务 CPU。扩容前先判断瓶颈属于模型配额、数据库、队列还是运行时 Worker，避免盲目加 Pod。

替代方案何时使用

低频内部平台可以先用单队列和定时扩容；实时客服和批量数据分析共存时，应拆优先级队列或资源池，并给关键租户预留并发。

常见扣分点

• 只给一个 QPS 数字，不说明调用扇出和外部配额。
• 只谈平均延迟，不谈首 token、P95 和排队时间。
• 长任务同步占用 HTTP 连接，超时后无法恢复。

Q16：工具和知识库怎样接入，平台如何防止能力越权？

参考答案

工具注册时除了名称和 JSON Schema，还应声明 owner、版本、调用 endpoint、超时、重试是否安全、数据分类、所需 scope、是否有副作用和确认级别。Agent manifest 只能引用已经批准的工具版本；运行时在每次调用前做三次检查：当前租户是否订阅、当前用户是否有 scope、当前任务是否满足风险和审批策略。工具服务收到调用后还要二次鉴权，不能因为请求来自平台 Worker 就默认信任。

知识库接入同样是授权问题。索引入库时保留文档 ACL、租户、来源和版本；查询时把用户身份和 Agent 身份带进过滤条件，再做检索和 rerank。模型只能看到通过权限过滤后的片段，引用展示也不能暴露用户无权打开的原文。文档被撤权或删除后，需要让索引和缓存尽快失效，并定义短暂传播延迟的安全边界。

外部网页、邮件和知识库文本都视为不可信数据。平台的系统指令、工具描述和权限策略由受信配置提供；模型输出只产生“工具意图”，实际参数还要经过 schema、范围、DLP 和业务规则检查。高风险写操作以 approval_required 返回给前端，不允许模型通过修改自然语言理由绕过。

替代方案何时使用

低风险只读工具可以采用统一服务账号加细粒度资源过滤；涉及删除、付款、发信或权限变更的工具应采用用户委托 token、短时凭证或专门审批服务，而不是长期共享密钥。

常见扣分点

• 把工具 schema 当作权限控制。
• 只在 Agent 配置时检查一次权限，不在每次运行时检查。
• 检索先召回全库再让模型“自己不要看”，这不是真正的 ACL 过滤。

Q17：平台如何处理长任务失败、重试和恢复？

参考答案

我会把一次 run 拆成有输入输出的步骤图，每完成一个可复用步骤就持久化 checkpoint。Worker 失败后，调度器根据步骤状态和租约判断是重新领取、等待依赖还是标记失败；已完成的证据检索不重复做，后续写作可以从 artifact 继续。每个步骤有错误分类：临时网络错误和供应商 5xx 可退避重试，schema 错误需要修复或换模型，权限拒绝和用户输入不足应转 WAITING_USER，副作用工具则必须先查询执行状态。

重试策略要同时限制次数、时间和预算，使用 run_id + step_id + attempt 做追踪，并以业务幂等键避免重复写入。对会发送消息、创建工单或修改数据的工具，采用 outbox 或工具侧幂等记录：平台先写“待执行事件”，执行结果回写后才推进状态；网络响应丢失时通过查询接口确认，而不是盲目再发一次。

用户取消时停止尚未开始的步骤，向正在运行的模型和工具传递取消信号；无法立即中断的调用也要在结果回来时丢弃其后续动作。平台保存失败原因、最后 checkpoint、已产生费用和建议操作，给用户一个可恢复的“从此处继续”入口。不可恢复的配置错误不能靠自动重试掩盖，应阻止发布并提示 builder 修改。

替代方案何时使用

极短的同步 run 可以在请求内完成并由网关超时保护；跨分钟甚至跨天、需要人工审批的任务必须用持久化工作流引擎或等价的事件状态机。

常见扣分点

• 所有异常都统一重试。
• Worker 重启后从第一步开始，成本和结果都漂移。
• 对外部副作用没有幂等和执行状态查询。

Q18：平台怎样做可观测性，如何定位“模型错了还是工具错了”？

参考答案

每个 run 建立 trace，下面有 step span 和 tool/model 子 span。核心字段包括 tenant、agent_version、run_id、step_id、model、route_id、prompt 模板 hash、输入输出 token、cached token、工具名、参数摘要、结果状态、耗时、重试、预算和安全决策。默认只记录脱敏摘要、哈希和引用 id；有权限的审计人员才能在保留期内查看加密原文。

一次任务的时间线应能回答：计划何时生成，检索返回了什么版本的证据，模型使用了哪个路由，为什么调用了这个工具，工具是否成功，是否发生 fallback，用户在哪一步确认，最终成本是多少。对于敏感字段使用字段级脱敏和访问审计，避免为了可观测性把完整邮箱、合同或源码复制到日志系统。

定位问题时按层切分：模型输出格式错，查看 prompt/schema/model；工具返回错误，查看 endpoint、scope、参数和外部服务；知识库答案错，查看 ACL、索引版本、召回和引用；平台恢复异常，查看事件重复、租约和 checkpoint。trace 不只是“把聊天全文打印出来”，而是让每个决策可关联、可过滤、可统计。

替代方案何时使用

个人开发阶段可以用结构化 JSON 日志；多租户生产平台应接入统一 trace、指标和事件存储，并配置采样、脱敏和保留策略，控制观测成本。

常见扣分点

• 只记录最终回答，没有中间步骤和版本。
• 把 token 和成本写在散落日志里，无法按租户聚合。
• 为了排障默认保存所有敏感原文。

Q19：平台级成本控制如何设计，怎样把账算到具体 Agent？

参考答案

每次 run 创建成本账本，按模型调用、embedding、rerank、工具、存储和人工审批分别记一条 usage line。模型调用记录输入、输出、缓存命中 token、重试、路由和价格版本；Agent、应用、租户和用户通过 run_id 关联，月底可以回答“哪个 Agent 的哪一步最贵、质量是否值得”。平台不能只按请求次数收费，因为一次长上下文和一次短分类的资源消耗差别很大。

预算分为租户月额度、应用日额度、Agent 版本额度、单 run 上限和单步骤上限。运行前预留，完成后按实际 usage 结算并释放差额；并发预留必须原子化。接近预算时可以发告警、限速、缩短上下文、使用低成本模型或转人工，但策略依赖风险等级：高风险 Agent 不得为了省钱绕过必要检查。

平台还要提供成本优化入口：缓存稳定检索和模型前缀、压缩历史摘要、限制无效工具循环、批量执行离线任务、使用小模型处理分类和抽取、对长文档分层处理。每项优化都要与质量指标一起看，例如平均成本下降但引用准确率下降，就不能视为成功。

替代方案何时使用

内部试用阶段可以先做软预算和报表，不立即拒绝请求；开放给多个团队后必须有硬上限和按租户归因，否则一个失控循环会影响全平台。

常见扣分点

• 只谈模型单价，不算存储、检索、工具和重试。
• 没有单 run/步骤预算，只有月底账单。
• 只优化成本，不验证回答质量和安全。

Q20：如何建立 Agent 的测试、评估和发布门禁？

参考答案

平台为每个 Agent 提供独立 eval 集，同时提供通用样本：正常输入、资料不足、越权请求、提示词注入、工具异常、重复消息、超长上下文和预算耗尽。评估结果分三层：任务结果是否正确，过程是否遵守工具和权限策略，系统是否满足延迟、成本和稳定性目标。平台级指标包括任务成功率、工具选择准确率、参数 schema 通过率、检索引用准确率、无答案识别率、安全违规率、人工介入率、P95 延迟和单位 run 成本。

发布前先做静态校验和离线回归，再做一段 shadow run。对影响较大的 Agent，按配置版本做成对比较或灰度分桶；不能只用 LLM-as-a-judge，至少用人工抽检校准事实、越权和关键业务指标。每个 Agent 可定义阻断阈值，例如安全违规率不能上升、结构化输出通过率不能低于旧版本、成本不能超过预算、关键业务准确率不能下降超过允许范围。

发布记录包含审批人、评估集版本、模型和工具版本、阈值结果、灰度范围和回滚版本。线上发现问题时，停止扩大流量并回滚 manifest；已有 run 按其原版本继续或安全终止，不能把运行中的配置热替换成新版本。评估集也要定期更新，防止团队只优化固定题目。

替代方案何时使用

探索阶段可以用少量专家抽检快速迭代；高风险或面向大量用户的 Agent 必须有可重复的回归集、自动门禁和人工审批，不能仅凭 demo 体验发布。

常见扣分点

• 把“能回答”当作通过标准，不测工具、权限和失败分支。
• 没有 eval 集版本，前后结果不可比。
• 只看平均分，不看高风险样本和尾延迟。

Q21：如何做多环境发布、灰度、回滚和配置漂移治理？

参考答案

我会把环境分成开发、测试、预发布和生产，每个环境有独立的密钥、工具 endpoint、知识库权限和数据策略；Agent 的逻辑 manifest 可以晋级，但环境绑定值由环境配置注入，不能把生产密钥提交进版本。发布单固定要晋级的版本 hash，经过评估门禁后由发布服务写入目标环境，避免运营人员手动复制 prompt 造成漂移。

灰度按租户、应用、用户组或稳定 hash 分桶，并为每个版本设置流量比例、开始时间、自动停止阈值和回滚目标。先做 shadow，再做 1% 低风险流量，观察任务成功率、人工转接率、工具错误率、安全拦截、P95 延迟、缓存命中和成本。高风险动作仍需确认，不因为灰度就放宽权限。版本回滚不只切模型，还要同时回滚提示词、工具 schema、知识库版本、guardrails 和路由策略。

平台持续做 drift check：比较数据库中的 active manifest、运行时缓存、Worker 加载版本和外部工具实际版本；发现 hash 不一致就告警或阻止新 run。已经产生的 trace 保留实际版本，不能只显示“当前 Agent 名称”。工具和知识库的向后不兼容变更采用新版本并保留旧版本一段时间，给在途任务完成和回滚留窗口。

替代方案何时使用

低风险内部 Agent 可以使用应用级开关快速灰度；面向外部用户或涉及写操作时，应使用发布单、审批、稳定分桶和自动回滚，不要靠人工改数据库开关。

常见扣分点

• 把灰度理解为只部署两套 Pod，没有请求分流和指标门禁。
• 回滚只回滚模型，忽略 prompt、工具、知识库和安全策略。
• 允许线上直接编辑配置，导致无法审计和复现。