基础概念
什么是 AI Agent
概念解释
Agent 就是利用大模型的能力封装的一个可以调用外部工具、拥有记忆、可以自主规划执行和完成任务的程序
业界常用一句概括：
Agent ≈ LLM + Planning(规划) + Memory(记忆) + Tools(工具)
- LLM： 大脑，负责理解、推理、生成自然语言与结构化计划。
- Planning： 把模糊目标拆成可执行步骤，并在执行中动态调整。
- Memory： 短期上下文 + 长期知识，避免「说完就忘」或重复劳动。
- Tools： 手脚，如搜索、数据库、代码执行、API 调用等。
与「普通 LLM 单次调用」的区别
- 普通调用：输入 Prompt → 模型输出文本，没有与外部环境闭环。
- Agent：输出往往是 「下一步动作」（例如：调用某工具、更新记忆、结束），环境返回 Observation（观察结果），再进入下一轮推理，形成 多轮控制循环。
自主决策能力体现在哪里
- 在动作空间中选下一步（选哪个工具、传什么参数、是否结束）。
- 在信息不完整时决定先澄清还是先假设再验证。
- 在失败时重试、换策略或请求人工介入（视系统设计而定）。
核心循环（典型 ReAct / Tool-use 范式）
抽象为：Thought（推理）→ Action（行动）→ Observation（观察）→ … → Final Answer。
实现上常由「编排层（Orchestrator）」驱动：解析模型输出、执行工具、把结果写回上下文，直到满足停止条件。
Agent 的「自主」是不是不受控？
强调 策略与护栏：工具白名单、工具黑名单、参数校验、人在回路（HITL）、预算与步数上限、输出审核；自主是在约束空间内的决策。
ChatBot 加上插件是不是就变成 Agent 了？
不一定。若插件调用由固定规则触发（例如关键词路由），更像「带工具的 Bot」。若由模型在多步推理中自主选择工具与参数，并形成闭环迭代，则更贴近 Agent。关键在是否具备多步自主决策与反馈闭环。
RAG + Chat 算不算 Agent？
单次检索再回答，偏「增强型 Chat」。若有多轮检索策略（查不到换查询、分解子问题、交叉验证），则具备 Agent 特征
ReAct 框架里三个字母代表什么？解决什么问题？
Reasoning + Acting：在生成中交替进行 推理（Thought） 与 行动（Action），并接收 观察（Observation）。它解决的是：模型仅「空想」容易偏离事实；通过 显式推理 + 工具反馈 把推理锚定在真实环境上。
Agent 的核心组成
-
感知（Perception）
把多模态输入（文本、文件、接口返回、页面结构等）转成模型可用的表示，并抽取任务相关状态。 -
规划（Planning）
把目标拆成子目标与步骤；可以是 一次性计划 或 每步重规划（re-plan）。 -
记忆（Memory）
短期：当前会话上下文、工具轨迹。
长期：用户画像、文档知识、向量库、图数据库等。 -
工具（Tools）
对外部世界可执行的操作抽象：需有清晰 schema（名称、描述、参数 JSON Schema）。 -
执行（Action）
真正调用工具或触发环境变化，并处理超时、重试、幂等等工程问题。 -
反思（Reflection）
对失败或质量不佳的结果进行自省：纠错、换策略、生成检查清单（常与「自我批评 / 验证器」配合）。
- 感知常与 结构化抽取、OCR、HTML 解析、日志解析 结合；关键是减少噪声进上下文。
- 规划常见实现：CoT / ReAct、Planner-Executor 双模块、树搜索（LATS）、任务图。
- 记忆工程要点：摘要压缩、引用溯源、记忆冲突解决、权限与隐私。
- 工具要点：最小权限、参数校验、错误信息回灌模型。
- 反思可做成独立子调用：「列出本次推理的三处风险并修正」。
Agent 的记忆一般怎么设计？
分层设计最常见：工作记忆（当前轨迹与关键结论）+ 会话记忆（摘要滚动）+ 长期记忆（向量检索/结构化库）。写入要区分「事实」与「推断」，并带时间戳与来源，便于更新与撤销。
规划和执行要不要拆开两个模型？
视任务而定。Planner-Executor 拆分可提升可控性（强模型规划、快模型执行）；
单模型端到端更简单但易在长链路漂移。
可混合：规划用强模型，执行层做确定性校验。
反思是不是必须？
不是必须，但对高 stakes 或易错工具场景收益大；成本是额外延迟与 Token。
Agent 的工作流程
可理解为：听懂 → 拆活 → 动手 → 对账 → 交卷。
-
输入处理
意图识别、指代消解、安全过滤、加载相关记忆与文档。 -
任务分解
生成子任务列表或决策树；复杂任务可配合 Human-in-the-loop 确认里程碑。 -
工具选择与调用
由模型或路由模块选择工具；执行器做鉴权、限流与结果规范化。 -
结果整合
合并多源信息，解决冲突（例如时间更新的数据优先）。 -
输出生成
面向用户的自然语言答案 + 可选 引用与操作轨迹（便于审计）。
如何避免 Agent 在工具调用间「迷失」？
- 明确 停止条件 与 最大步数；
- 维护 任务清单（todo） 与 当前子目标；
- 对每步输出要求 结构化（JSON）；
- 关键步骤 强制验证（单元测试式检查、二次 LLM 审核）。
结果冲突怎么整合？
优先级规则（权威源 > 时间新 > 多源一致）、让模型显式输出「冲突说明」、必要时触发人工。
Agent 的应用场景
结合「高频、可工具化、可评估」的场景优先落地。
-
智能客服
工单查询、订单状态、退换货政策；需 知识库对齐、身份鉴权、升级人工 策略。 -
代码助手
读仓库、跑测试、提 PR；需 沙箱、diff 审查、最小权限。 -
数据分析
NL2SQL、制图、解读；需 数据治理、行级权限、结果校验。 -
自动化运维
查日志、重启服务、开单；需 审批流、灰度、回滚。 -
知识管理
摘要、标签、关联检索；需 溯源、版本、权限。
企业内部落地 Agent，你最先关心哪三个非功能需求？
- 安全与合规（权限、审计）
- 可控性（人在回路、工具白名单）
- 可观测性（轨迹、指标、回放）。
客服场景如何降低幻觉？
强 RAG 溯源、禁止无引用断言、模板化答复、未知则转人工。
Agent 的挑战与局限
Agent 把能力做强的同时，把 错误放大 到多步；工程上要「限步、限权、可观测、可回滚」。
-
幻觉
模型编造事实或工具参数；对策：检索 grounding、约束解码、验证器。 -
安全性
Prompt 注入、工具滥用、数据外泄；对策：分层信任域、输出过滤、秘密不入模型上下文。 -
成本控制
长链路 × 大上下文；对策：摘要、小模型路由、缓存、批处理工具。 -
可解释性
提供 轨迹、引用、决策日志；关键操作 可回放。 -
评估困难
单轮 BLEU 不适用；需 过程指标（工具是否正确）、结果指标（任务是否完成）、人工抽检。
怎么评估一个 Agent 的好坏？
分层评估：任务成功率、平均步数/成本、工具错误率、用户满意度、安全事件数；基准可包括静态数据集 + 仿真环境 + 线上 A/B。
Agent 的最大风险是什么？
复合错误与权限滥用——单步小错在多步放大，或工具被诱导执行高危操作；因此必须 最小权限 + 强审计 + 人在回路。
如何防止 Prompt 注入？
工具层鉴权与用户身份绑定、结构化分隔用户内容与指令、敏感操作二次确认、输出侧 DLP。
综合题
你会如何设计 Agent 的停止条件？
组合使用：模型声明 finish、任务清单全部完成、达到步数/预算上限、超时、连续无进展检测、外部成功信号（如测试通过）。生产环境必须有 硬上限 防止死循环。
工具描述（tool description）为什么非常重要
模型靠描述做 工具选择；描述不清会导致 选错工具、参数幻觉。好的描述包含：何时用、何时不用、参数含义、错误示例、返回格式。
Memory 用向量库就够了吗？
不够。向量检索擅长相似度，但弱于精确约束与关系推理。工程上常见 向量 + 关键词/结构化库 + 图谱（按需），并维护 元数据与权限。
多 Agent 协作和单 Agent 多工具怎么选？
- 单 Agent 多工具：实现简单、延迟低，适合任务边界清晰。
- 多 Agent：角色分工、并行探索、对抗审查（如「批评者 Agent」）；但带来 协调成本与一致性 问题。
选型看 任务分解结构、组织边界、延迟与成本。
如何做「人在回路」又不打断体验？
分级：低风险自动执行；
中风险 异步审批；
高风险 实时确认。
产品上 预授权（例如仅本次会话可读某目录）、可撤销、默认最小权限。
为什么「让模型自己选工具」可能不如「路由器 + 规则」？
在 域窄、路径稳定 的场景，路由器更 省成本、可测试、行为确定；
全模型路由在 开放域 更灵活。
最佳实践常是 混合：易分类走规则，难例走模型。