面试题 · Prompt
搜索「并行」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
如果您需要从头设计一个大模型智能体系统，请描述您的设计思路、架构选择和关键技术考量
感知层（Perception）
认知层（Cognition）
执行层（Action）
按学习路线查看教程、项目和面试题。
| 维度 | 设计选择 |
|---|---|
| 记忆系统 | 短期：对话上下文滑动窗口；长期：向量库+结构化知识图谱双存储 |
| 工具调用 | Function Calling原生支持 + 动态工具检索（相似度匹配Top-K） |
| 规划深度 | 简单任务单步响应；复杂任务启用多步ReAct，设置最大迭代阈值 |
| 安全可控 | 输出审核层（敏感词+意图分类）；工具调用权限白名单 |
| 扩展性 | 插件化架构，新工具自动注册无需改代码 |
核心原则：不是让Agent更"聪明"，而是让系统更"可靠"——通过明确的边界、完善的监控和优雅的降级策略保障生产可用。
场景切入
假设我们要做一个电商客服智能体，用户问‘帮我查一下上周的订单’，然后又说‘顺便把那个退款申请提交了’。你会怎么设计这个系统，让它能理解用户意图、调用订单API和退款接口，还要记住上下文？从头说说你的思路。
层层追问
你觉得一个智能体系统最关键的能力是什么？……那规划能力怎么实现？比如用户说‘帮我订机票，再订个酒店，要便宜的’，系统怎么一步步执行？……好，那工具调用怎么保证安全？……记忆方面呢，短期和长期怎么设计？
直球架构
让你从零设计一个大模型智能体系统，说说你的分层架构、记忆系统、工具调用机制和规划策略，还有安全怎么考虑。直接讲设计思路和关键技术点。
我觉得这道题问的其实不是怎么搭一个花哨的[[Agent]]，而是你怎么保证它在生产环境里稳定可用。说白了，大模型智能体系统，核心不是让模型更聪明，而是让整个系统更可靠。
我的设计思路是三层分离：感知层、认知层、执行层。先说感知层，它负责把[[多模态]]输入，文本、图像、语音，统一编码成模型能理解的表示，同时做意图识别和上下文管理。这里有个边界划分：如果输入全是结构化查询，比如订单号检索，那感知层可以很轻，甚至直接用规则路由；但如果是开放域对话，就得靠模型做语义理解，上下文窗口管理就特别重要，得动态压缩历史，不然窗口一满就丢信息。实际落地往往是两者结合，规则兜底，模型处理模糊情况。
认知层是核心，负责推理和规划。我支持多种推理范式，比如简单任务单步响应，复杂任务走 [[ReAct]] 或 [[Chain-of-Thought]] 多步推理。这里有个坑：规划深度不是越深越好。比如客服退款场景，用户说“我要退款”，如果直接调用退款工具，可能忽略订单状态、库存信息，导致执行失败。所以我加了反思机制：执行后自我评估，失败就重规划，并设置最大迭代阈值防止死循环。
执行层是工具调用的沙箱。我会用标准化的 [[Function Calling]] 接口，工具注册中心管理所有工具的 Schema。工具调用必须隔离执行，加超时控制和权限分级。比如企业 SOP 文档查询，只允许读操作，不允许改数据库。工具调用的权限白名单是安全底线，上线前必须审计。
记忆系统我分成短期和长期。短期用 [[Sliding Window]] 保存对话上下文；长期用[[向量库]]加结构化[[知识图谱]]双存储。向量库适合语义检索，知识图谱适合精确关系查询。比如用户问“上次那个退款订单怎么样了”，向量检索找到相关对话片段，知识图谱确认订单状态，两者互补。
安全和可控性方面，输出审核层用敏感词加意图分类过滤，工具调用权限白名单。扩展性靠插件化架构，新工具自动注册不用改核心代码。
这里有个延伸点：成本感知调度。我会根据任务复杂度动态选择模型，简单任务用小模型，复杂任务用大模型，甚至结合 [[MoE]] 路由。但前提是模型质量评估准确，否则小模型误判会降低用户体验。
[[多智能体]]协作方面，我倾向用主从架构：主 Agent 负责任务分发，子 Agent 并行执行，通过共享内存池通信。但协作成本不低，通信协议要轻量，避免序列化开销。
最后我的判断是：Agent 系统成败不在模型多强，而在边界划得多清楚、降级策略多优雅。所以我更倾向把精力花在监控、回滚、人工确认回路上，而不是一味堆功能。如果面试官有兴趣，我可以再讲讲成本感知调度的具体实现。