4399 AI Agent 开发笔试：高并发架构、工具安全与多Agent协作

《面试题目》

一、单选题（共 8 道，原帖截取 2 道）

1. 高并发 IM 系统的后端架构（5 分）：公司要为支持数十万级同时在线用户的 IM 系统设计后端，用户连接为短连接、消息收发频繁，对服务器并发和资源利用率要求极高。在 Linux 环境下，下列哪种后端技术架构最适合该场景的高并发高性能需求？

   • A. 多进程模型，每个进程负责一部分连接，通过共享内存实现进程间通信
   • B. 事件驱动的异步 IO 模型（如 epoll/kqueue），采用单进程或少量多线程协作处理所有连接
   • C. 多线程模型，主线程负责监听，工作线程池处理每个短连接的业务逻辑，采用同步 IO 读写
   • D. 传统阻塞式 IO 模型，每个连接分配一个线程，利用线程池管理

2. 采购 Agent 的安全边界：采购 Agent 会读取供应商网页并调用内部工具创建采购申请，网页可能诱导模型修改收货地址或提高采购数量。在模型仍可能受诱导的前提下，哪种措施最能构成可靠安全边界？

   • A. 根据用户权限、原始需求和业务规则，在工具执行层校验采购参数及操作范围
   • B. 让另一个模型审核主 Agent 的计划
   • C. 使用独立模型检查网页内容，检查通过后完全信任
   • D. 只在系统 Prompt 中声明网页命令不得执行

二、讨论题（共 3 道）

3. 个人助理 Agent 的长期记忆（10 分）：一个长期使用的个人助理 Agent 应该记住用户哪些信息？哪些信息不应该直接写入长期记忆？请进一步设计写入、冲突、过期、查看和删除机制，并说明如何验证系统不会把模型猜测当成用户事实。

4. 工具调用的接口设计（15 分）：为 create_ticket 设计一个 JSON Schema 或接口契约，包含参数校验、幂等、防重复提交、权限校验、确认语义和可观测 trace；再给出 3 个会导致线上事故的反例输入，并解释分别如何被拦截。

5. 多 Agent 协作流程设计（18 分）：某企业报告生成流程由资料检索 Agent、数据分析 Agent、报告撰写 Agent 和发布 Agent 协作完成。实际运行中出现了资料版本过期、分析结果缺少来源、多个 Agent 反复互相退回任务、发布 Agent 申请超出职责的权限，以及某个子任务失败导致整条流程卡死。请设计一套可落地的协作编排、权限控制、异常恢复和评测方案。

三、编程题：警察与小偷的追捕游戏

6. 城市布局用无向图表示，节点为路口、边为街道。小偷从路口 1 开始逃跑，警察从路口 2 开始追捕；路口 0 是安全屋，小偷进入即成功逃脱，警察不能进入路口 0。双方轮流行动（小偷先动），每次必须移动到相邻路口。警察和小偷在同一路口则警察获胜；小偷进入安全屋则小偷获胜；相同状态重复出现（双方位置 + 轮到谁移动）则平局。给定邻接表 graph，假设双方都采取最优策略，判断游戏结果：返回 1 表示小偷获胜，2 表示警察获胜，0 表示平局。约束：3 <= n <= 50，graph[i] 元素互不相同且不含自环，图连通。示例：graph = [[2,5],[3],[0,4,5],[1,4,5],[2,3],[0,2,3]]，输出 0，双方最优策略将导致无限循环。

四、开放讨论题

7. 说说你最近使用 AI 解决的最大的问题：问题背景是什么、使用了哪个模型、使用了什么提示词，以及在模型输出后你是怎么优化的。

《参考解析》

高并发 IO 模型：这题应选 B。短连接、连接数巨大而单连接业务很轻，瓶颈在连接管理与线程上下文切换，不在计算；epoll/kqueue 的就绪通知配合非阻塞 IO，用单进程或少量线程（多 reactor）就能撑起十万级连接。一连接一线程或同步 IO 会让工作线程大量阻塞在读写上，多进程方案则要额外处理共享内存与进程间通信。落地时还要注意边沿触发必须一次读到 EAGAIN、避免惊群，CPU 密集的逻辑另派线程池，不能堵住事件循环。

Agent 安全边界：应选 A。供应商网页属于不可信输入，系统 Prompt 声明和「另找一个模型审核」都只是概率性防御，模型被诱导时同样可能绕过。可靠边界必须落在确定性代码上：工具执行前按用户身份、原始需求和业务规则校验参数，包括金额、数量、收货地址白名单和审批阈值，越权直接拒绝并留审计记录。再配合最小权限、不可信内容与指令隔离、高风险操作二次确认和全链路 trace，才算是工程上的边界。

长期记忆：先分层——稳定事实（身份、长期偏好）、任务情景（在做的项目、近期目标）可以记，证件号、健康、财务等敏感信息默认不写或需显式授权。写入流程应是「抽取候选 → 附来源与置信度 → 用户确认或高置信规则 → 落库」，模型推断只能停留在候选区。冲突按来源优先级处理（用户显式更正 > 用户原话 > 模型推断），保留时间戳与旧值；过期用 TTL 加定期复核；用户要能查看、更正、删除，且删除要覆盖由它衍生的记忆。验证靠 provenance 字段、人工标注集统计「猜测被写成事实」的比例，以及可审计的记忆变更日志。

多 Agent 协作：编排用显式状态机或工作流引擎，每个环节的输入输出带版本号和来源，检索结果返回文档 id 与版本，分析结论必须引用来源 id，缺失就校验失败。互相退回要设次数上限，超限升级人工，避免两个 Agent 打乒乓。权限按 Agent 拆开最小化，发布 Agent 只能调用发布工具，越权申请由工具网关拒绝。子任务失败走重试、补偿、降级或死信队列，不能拖住整条流程。评测用固定 case 集加端到端 trace，度量成功率、返工率、越权次数和时延。

博弈编程题：把状态定义为（小偷位置，警察位置，轮到谁移动），共 2 * n * n 个。终局直接标记：同位置为警察胜，小偷在 0 为小偷胜。然后做逆向归纳（retrograde BFS）：某状态存在一步能走到「己方必胜」，它就是必胜；所有走法都通向「对方必胜」，它就是必败；剩下的未定状态即平局。实现上用队列加出度递减，复杂度约为 O(n² + E)，不要用普通 DFS 判环，那样分不清平局和必胜。