完整题目
请谈谈你对AI Agent技术架构和应用场景的理解，可以结合具体项目经验进行说明。
本文目录
核心架构
Agent 不是“模型加几个工具”，而是一个带状态、约束和反馈的执行系统。生产架构通常包含：
- 入口与策略层：认证、限流、意图识别、风险分级和预算。
- 规划与状态层：维护目标、步骤、依赖、当前状态和终止条件；确定性流程优先用状态机。
- 工具层：工具 schema、参数校验、权限、超时、幂等、重试、熔断和结果校验。
- 记忆与知识层：短期状态、长期记忆与 RAG 分开治理，并执行租户隔离和删除策略。
- 安全与人工层：敏感动作审批、最小权限、提示注入防护和审计。
- 观测层：记录 trace、模型与 Prompt 版本、工具输入输出、token、延迟、错误码和回退路径。
教学假设：数据分析 Agent
假设系统接收自然语言分析请求。流程可以是：识别数据域 → 检索 schema 和口径 → 生成查询计划 → 生成 SQL → 静态校验与只读执行 → 结果一致性检查 → 生成解释。删除、写入或高风险查询必须经过授权，不由模型直接执行。
失败与取舍
常见失败包括 schema 幻觉、工具循环、状态丢失、外部 API 超时、权限越界和成本失控。应分别用检索真实 schema、最大步骤、检查点、截止时间传播、能力令牌和预算上限处理。简单固定流程使用工作流通常比自由 Agent 更稳定。
实验设计
在固定任务集上比较“规则/工作流”“单 Agent”“带检索或多 Agent”的任务成功率、工具参数合法率、人工接管率、P95/P99、成本和安全事件。只有受控实验才能说明增加 Agent 复杂度是否值得。
换一种问法，检查是否真正理解
场景切入
假设你在做一个智能客服，用户问“帮我查一下上个月的订单”，然后又说“把销量前十的列出来”。如果只做RAG，查完知识库就停了；但Agent需要去调数据库、跑统计、再出结果。你具体怎么设计这种“能干活”的系统？
层层追问
你刚才提到RAG，那你能不能讲讲RAG和Agent的核心区别？……好，那Agent的架构里，你觉得最关键的几个组件是什么？……如果我要做一个数据分析助手，自然语言查数据库，你怎么设计它的规划和工具？
直球架构
请你谈谈对AI Agent技术架构的理解，包括核心组件和它们之间的关系。然后结合一个具体业务场景，说明你如何做设计取舍，以及落地时遇到过哪些关键挑战。
练习口述回答 · 约4分钟
- Agent vs RAG本质区别
- 核心架构组件
- 智能数据分析助手项目
- 落地风险与取舍
这是一道架构设计题，下面使用明确的教学假设，不代表任何个人项目。
先把 Agent 看成带状态和约束的执行系统。入口层负责认证、限流和风险分级；规划层维护目标、步骤、依赖与终止条件；工具层提供 schema、参数校验、权限、超时、幂等、重试和熔断；记忆与 RAG 分开管理，并按租户隔离；高风险动作进入人工审批；观测层记录模型、Prompt、工具调用、状态变化、token、延迟和错误。
假设设计一个数据分析 Agent：用户问题先被路由到数据域，系统检索真实 schema 和指标口径，再生成查询计划与 SQL。SQL 必须经过语法、表权限、扫描量和只读检查，执行结果还要做空值、量纲和一致性校验，最后才生成解释。删除或写入操作不能由模型直接执行。
失败模式也要分层处理。schema 幻觉用真实元数据检索约束；重复调用用最大步骤和循环检测；中断用检查点恢复；外部服务用截止时间、重试预算和熔断；越权用最小权限与审计；成本用 token、工具和总时长预算限制。
是否需要 Agent 应通过实验决定。在同一任务集上比较工作流、单 Agent 和更复杂方案的任务成功率、参数合法率、人工接管率、延迟、成本与安全事件。如果固定工作流已经满足要求，就没有必要增加自主规划。
架构边界还要说明记忆不等于把全部历史塞回 Prompt。会话状态保存当前任务所需字段，长期偏好需要来源、时间、置信度、可删除和租户边界，知识库保存可复用事实；三者生命周期不同。模型生成的摘要不能自动成为可信事实，关键状态应来自工具或用户确认。工具结果也不能直接信任，要校验 schema、业务状态和权限。
数据分析假设中，生成 SQL 只是中间产物。系统还要限定可访问的数据集、最大扫描量、超时、敏感列和只读事务；查询结果为空或异常时，Agent 应返回证据不足，而不是改写结论。自然语言解释需要携带口径与查询版本，方便复现。若用户要求写入或发送报告，则进入新的授权动作，不能沿用只读权限。
对比实验不仅看任务是否完成，还要看错误动作的严重度。工作流可能覆盖率低但稳定，Agent 可能覆盖更多长尾却增加不可预测错误；多 Agent 可能并行但状态同步更难。选型应根据风险加权任务成功、人工成本和故障恢复，而不是只看平均完成率。