AI Agent 知识点详解

什么是 AI Agent？它和单次 LLM 调用、Workflow 有什么区别？

定义

AI Agent 是以 LLM 为「大脑」的自主系统：LLM 不仅能生成文本，还能规划任务、调用工具、观察结果、迭代决策，在环境中自主完成目标。

核心四要素：感知（输入）→ 规划（Plan）→ 行动（调用工具）→ 记忆（上下文/状态）。

vs 单次 LLM 调用

• 单次调用：一问一答，无工具、无状态、无多步。
• Agent：多步循环，可调工具、可自我修正，直到完成目标。

vs Workflow

• 实践：能 Workflow 固定就用 Workflow，确需动态决策才上 Agent（更可靠）。

ReAct 范式是什么？Thought/Action/Observation 各是什么？

ReAct

Reasoning + Acting：把「推理（Reason）」与「行动（Act）」交替进行，让 LLM 边想边做。

三要素

Thought: 我需要先查今天的天气，再决定穿什么
Action:  search_weather(city="北京")
Observation: 北京今天 18°C，多云
Thought: 天气偏凉，建议穿外套
Final Answer: 建议穿一件薄外套

• Thought：当前该怎么推理/计划（模型内部思考）。
• Action：调用哪个工具、传什么参数（结构化输出）。
• Observation：工具返回结果，作为下一步输入。
• 循环直到 Final Answer。

意义

• 把推理与外部工具结合，让模型能多步求解需要外部信息/计算的复杂任务。
• 是大多数 Agent 框架（LangChain Agent、AutoGPT）的底层范式。

Function Calling / Tool Use 的原理是什么？如何实现？

原理

LLM 本身不能执行动作，Function Calling 让模型输出「要调哪个函数 + 参数」的结构化指令，由宿主程序真正执行，再把结果回传给模型。

实现步骤

1. 定义工具 schema：用 JSON Schema 描述函数名、参数、说明。
2. 模型生成调用指令：模型输出 {name: "get_weather", arguments: {city: "北京"}}。
3. 宿主执行：程序按指令调用真实函数/API。
4. 回传结果：结果拼进上下文，模型继续生成。
5. 循环直至完成。

{"name": "get_weather", "arguments": {"city": "北京"}}

关键点

• 工具描述要清晰（名称、用途、参数说明），直接影响模型能否正确选工具。
• 需处理调用失败、参数错误、重试。
• 支持多工具时，模型做「工具选择 + 参数抽取」。

Agent 的规划能力如何实现？Plan-and-Execute 和反思有什么区别？

规划能力

让 Agent 对复杂任务拆解步骤、按序执行、动态调整，而不是一步到位。

主要方法

Plan-and-Execute vs 反思

• Plan-and-Execute：事前规划，先出计划再执行，适合步骤明确的任务。
• 反思（Reflexion）：事后复盘，失败时分析原因、改策略重试，适合需迭代的任务。
• 两者常组合：先规划，执行失败时反思调整。

Agent 的记忆如何设计？短期记忆和长期记忆有什么区别？

记忆分类

短期记忆设计

• 就是对话历史放进上下文；受上下文窗口限制，需截断/摘要/滑动窗口管理。
• 摘要式：把早期对话压缩成摘要，节省 token。

长期记忆设计

• 向量记忆：把重要信息 embedding 存入向量库，按需检索（类似 RAG 但存的是「经历」）。
• 结构化记忆：用户画像、偏好存数据库/知识图谱。
• 反思记忆：定期把会话提炼成长期要点（如 Generative Agents 的 memory stream）。

工程要点

• 记忆的写入时机、检索策略、遗忘机制都要设计；避免无关记忆污染上下文。

多 Agent 协作有哪些模式？常见框架有哪些？

协作模式

常见框架

• LangGraph：基于图的状态机，可编排多 Agent 与流程。
• AutoGen（微软）：多 Agent 对话式协作。
• CrewAI：角色化团队（Role-based）协作。
• MetaGPT：模拟软件公司 SOP 的多 Agent。

何时用

• 单 Agent 能做就单 Agent；任务可拆解、需不同专长时才上多 Agent（成本与复杂度更高）。

什么是 MCP 协议？它解决什么问题？

定义

Model Context Protocol（MCP，Anthropic 提出）：LLM/Agent 与外部工具、数据源之间的标准化协议，类似「AI 世界的 USB-C 接口」。

解决什么问题

• 此前每个模型要接入每个工具都需定制开发（M×N 集成）。
• MCP 统一了「工具/资源/提示」的调用规范：一个 MCP Server 可被任何支持 MCP 的客户端（Claude、IDE 等）复用（M+N 集成）。

组成

• MCP Server：暴露工具/资源的服务端。
• MCP Client：Agent/应用侧，发现并调用 server。
• 通过 JSON-RPC 通信，支持工具、资源、提示三类能力。

意义

• 工具生态互通、降低集成成本，是 Agent 工具标准化的方向。

LangChain、LangGraph、AutoGen、CrewAI 这些框架有什么区别？

对比

选型

• 简单链式/原型 → LangChain。
• 复杂可控流程、需精确状态控制 → LangGraph。
• 多 Agent 协作 → AutoGen/CrewAI。
• 数据检索优先 → LlamaIndex。

如何保证 Agent 的可靠性？如何避免死循环和失控？

常见问题

死循环（重复调同一工具）、跑偏、token 爆炸、错误累积。

保障手段

• 循环检测：限制最大步数、检测重复 Action 及时终止。
• 超时与预算：设单步/总超时、token 预算、成本上限。
• 错误重试与降级：工具失败重试 N 次后降级或转人工。
• 人工确认（Human-in-the-loop）：关键操作（支付/删除）需人工批准。
• 结构化约束：工具调用用严格 schema、约束输出格式。
• 可观测与日志：记录轨迹，事后审计与调优。
• 沙箱与权限：工具限权、隔离执行环境。

如何评估 Agent 的效果？

评估维度

• 任务成功率：端到端完成率（核心指标）。
• 轨迹质量：中间步骤是否合理、是否高效（步数、token 消耗）。
• 工具调用准确率：选对工具、参数正确。
• 鲁棒性：干扰/异常下的表现。
• 成本：token 与延迟预算。

评估方法

• 基准测试：如 WebArena、GAIA、AgentBench、SWE-bench（软件工程 Agent）。
• LLM-as-judge：用强模型评估轨迹/答案质量。
• 人工评估：复杂任务需人工判分。
• 分步评估：拆「规划质量、工具调用、最终结果」分别打点。

Agent 落地有哪些难点？为什么说 Agent 落地难？

难点

1. 幻觉放大：多步推理中幻觉会逐级累积，一步错步步错。
2. 工具不可靠：工具结果格式/语义不稳定，模型难以处理。
3. 长程任务失败率高：步数越多，成功率指数下降。
4. 成本与延迟：多步 + 长上下文，token 消耗大、慢。
5. 可控性/安全：难保证行为边界，易出意外操作。
6. 评估困难：开放任务难以自动评估，迭代慢。

为什么难

• 本质是「不确定的模型 + 不确定的环境 + 多步累积误差」三者叠加，可靠性难以保证。
• 生产常退化为「受限 Agent / 强约束 Workflow」来换取可控性。

Agent 有哪些安全风险？如何防护？

安全风险

1. 提示注入（Prompt Injection）：外部内容（网页/文档/工具返回）夹带恶意指令，诱导 Agent 执行。
2. 越权操作：Agent 调用工具超出权限（删数据、转账）。
3. 数据泄露：把敏感数据传给外部工具/模型。
4. 工具滥用：被诱导调用危险工具。

防护手段

• 最小权限：工具按角色最小授权，不暴露危险能力。
• 人工确认：高危操作（支付/删除/发消息）需批准。
• 输入隔离：区分「指令」与「数据」，外部数据当数据不当指令。
• 输出过滤/沙箱：隔离执行、审计日志。
• 敏感数据脱敏：传外部工具前脱敏。
• 提示注入检测：检测并隔离外部可疑指令。

如何设计工具（tool）的 schema？有哪些要点？

tool schema 设计

tool schema 用 JSON Schema 描述模型「看到的接口」：name（函数名）、description（做什么/何时用）、parameters（参数 schema）。

{
  "name": "get_weather",
  "description": "查询指定城市的实时天气，返回温度与天气状况",
  "parameters": {
    "type": "object",
    "properties": {"city": {"type": "string", "description": "城市名，如 '北京'"}},
    "required": ["city"]
  }
}

description 写作要点

• 差：description: "处理数据"；好："把 CSV 按某列聚合求和，返回 JSON 结果"。

parallel function calling 是什么？如何实现？

定义

模型在一次响应中返回多个 tool call，宿主并行执行后一次性回传结果，减少多轮往返。

好处与机制

• 好处：把「查北京天气 → 查上海天气」这类无依赖的多个调用合并，降低延迟与 token。
• 机制：模型输出一个 tool_calls 数组；OpenAI 可用 parallel_tool_calls 参数开关，Claude 默认支持。

用户: 查北京和上海的天气
模型: [get_weather(北京), get_weather(上海)]   ← 一次返回两个调用

注意

• 只有无依赖的工具才能并行；有依赖（A 的结果是 B 的输入）必须串行。
• 并行后需按 tool_call_id 把结果一一对应回传。

工具调用失败如何处理？

失败类型

处理流程

1. 捕获错误并结构化回传：把 error message（含错误码/原因）作为 tool 结果喂回模型。
2. 模型自纠重试：模型根据错误信息重新生成参数，通常能修正。
3. 限次重试 + 降级：重试 N 次（如 3 次）仍失败则换工具/简化目标/转人工。
4. 兜底提示：给模型明确失败信息而非吞掉错误。

• 关键：错误信息要回传，让模型「看到」失败原因才有机会修正。

工具结果如何回传给模型？有哪些方式？

回传结构

工具执行后，宿主把结果拼进消息列表，用 tool role 回传，并通过 tool_call_id 与模型发起的调用一一对应。

{"role": "tool", "tool_call_id": "call_123", "content": "{\"temp\": 18, \"weather\": \"多云\"}"}

要点

• 必须带 tool_call_id：让模型知道这个结果回答的是哪次调用。
• 结果序列化：通常转 JSON 字符串；大结果需截断/摘要防止爆上下文。
• 标注来源/状态：可附 status: success/error 与耗时元信息。
• 模型拿到结果后继续生成下一步（可能再调工具或给 Final Answer）。

function calling 和 tool use 有什么区别？

区别

结论

• 二者本质一致：都是「模型不直接执行，输出 {name, arguments} 由宿主执行」。
• 区别主要在术语与生态：Function Calling 偏「函数」，Tool Use 泛指任意工具/能力（浏览器、代码、API）。
• 面试中可互换使用，但要点出「结构化指令 + 宿主执行」的共同内核。

CoT 和 ReAct 有什么区别？

定义

• CoT（Chain-of-Thought）：让模型逐步推理，把思考过程写出来，但不调用外部工具，纯「想」。
• ReAct：Reasoning + Acting，推理与「调用工具 + 观察结果」交替，边想边做。

对比

联系

• ReAct 把 CoT 的「推理链」扩展为「推理-行动-观察」循环，解决 CoT 无法获取外部信息、易幻觉的问题。

什么是 ToT（Tree of Thoughts）？

定义

Tree of Thoughts（思维树）：把推理过程建模成树状搜索——每一步生成多个候选「想法」，评估后选择/回溯，而不是 CoT 的单条链。

过程

1. 分解：把问题拆成若干中间步骤。
2. 生成候选：每步让模型给出多个候选想法。
3. 评估：用打分模型/投票给候选打分。
4. 搜索：用 BFS/DFS 扩展最有希望的节点，可回溯换分支。

vs CoT

• 适合数学、规划、搜索等可回溯任务；成本高，生产中少用。

什么是 self-consistency？

定义

Self-Consistency（自一致性）：对同一问题采样多条推理路径，取「多数投票」的结果作为最终答案，用于降低单次采样的随机错误。

原理

• 单次采样可能因随机性出错；但「正确答案往往会被多数采样命中」，投票可放大正确信号。
• 常与 CoT 搭配：先让模型生成多条思维链，再对最终答案投票。

参数与注意

• 采样次数：典型 5/10/40 次，越多越稳但成本线性上升。
• 只适合有唯一确定答案的任务（数学/逻辑/代码），开放式问答不适用。
• 与 ToT 区别：Self-Consistency 是「多链投票」，不主动回溯搜索。

Reflexion 的完整流程是什么？

四阶段

1. Actor：生成一段轨迹（行动与观察）
2. Evaluator：评估结果（测试/打分），失败则进入反思
3. Self-Reflection：模型用自然语言总结「哪里错、怎么改」→ 得到 verbal reinforcement
4. Memory：把反思存入 episodic memory，下次重试时带上

关键点

• 反思是语言形式的强化信号，而不是梯度更新——把「教训」写进下一轮的提示。
• 与 ReAct 关系：在 ReAct 循环之上，失败后多一层事后复盘。
• 反思内容模板：上一次失败因为 X，改进策略：下次 Y。

效果

• 多次迭代后成功率逐步提升，适合代码生成、决策类任务。

计划如何修正？plan 修正有哪些策略？

初始规划

• 规划器（Planner）把任务拆成步骤列表：每步有描述、预期结果、依赖。

执行与修正

loop:
  取下一个未完成步骤 → 执行 → 观察结果
  if 结果与计划不符: 调用 replanner 重新生成剩余步骤
  if 出现新信息/新子任务: 插入或改写步骤

• replan 机制：每步执行后把「已完成 + 观察 + 原始计划」喂给模型，让它决定「继续/修改/终止」。
• 状态跟踪：步骤标记 pending/running/done/failed，失败步骤触发重试或改写。

工程要点

• 计划存成结构化对象（含依赖、状态），便于增量更新而非整体重排。
• LangGraph 中 Planner + Replanner 用两个节点 + 条件边实现。

子任务分解中的依赖关系如何处理？

分解方法

• 目标分解：大目标 → 子目标 → 可执行步骤（自上而下）。
• 任务树/DAG：把子任务组织成有向无环图，表达执行顺序。

依赖类型

管理手段

• 用任务列表（结构化为 {id, desc, deps, status}）跟踪，执行前检查前置是否完成。
• 拓扑排序决定执行顺序；失败传播时只重跑受影响分支。
• 让 LLM 输出结构化子任务（带依赖字段），再由执行器调度。

什么是 self-correction？如何实现？

定义

Self-Correction：让模型检查自己的输出、发现并修正错误，形成「生成 → 批评 → 修正」的反馈回路。

实现方式

• 自我检查（Self-Refine）：生成后用另一个 prompt 让模型 critic 自己的答案并改进。
• 外部信号驱动：用真实反馈（代码运行结果、测试、工具报错）驱动修正，比纯自评更可靠。
• 约束/校验：结构化校验（JSON 合法性）、重采样修正。

局限

• 纯「自我感觉」的检查可能失效（模型对自己错误盲视）；最好有外部验证信号（执行结果、测试、检索比对）。
• 可配合 Reflexion：多轮失败后的反思是更强的 self-correction。

短期记忆的窗口如何管理？

三种手段

组合实践

• 滑动窗口 + 摘要：超出窗口的早期对话先摘要再丢弃，兼顾信息与成本。
• 参数：窗口大小（如最近 10~20 轮）、摘要触发阈值（如超 8k token 时压缩）。
• 保留「系统提示 + 关键约束 + 最近对话」三段式，确保目标不漂移。

长期记忆的写入、检索和遗忘如何设计？

写入（何时存）

• 事件驱动：重要决策、用户偏好、纠错教训（Reflexion 的反思）。
• 定期：会话结束把要点蒸馏入库；避免全量塞入噪声。

检索（何时取）

• 按相关性 + 时效 + 重要性打分排序，取 top-k 注入上下文。
• 参考 Generative Agents 三权重：recency（新近）· importance（重要）· relevance（相关）。

遗忘（何时删）

• TTL 过期：超时删除或降权。
• 容量上限：超过上限淘汰低分记忆。
• 巩固/衰减：重要记忆反复调用强化，久未使用衰减。

episodic memory 和 semantic memory 有什么区别？

区别

在 Agent 中

• Episodic：会话轨迹、反思教训（memory stream 的事件流）。
• Semantic：提炼后的稳定知识（用户画像、领域规则）。
• 记忆系统常是两层：原始事件流 → 蒸馏成语义记忆。

什么是记忆蒸馏？

定义

记忆蒸馏：会话结束后，用 LLM 把冗长的原始对话提炼成结构化、可复用的长期记忆，丢弃噪声。

做法

1. 取原始对话 → 让 LLM 抽取：关键事实、用户偏好、结论、待办。
2. 结构化输出：{entity, attribute, value, confidence} 或自然语言要点。
3. 写入长期记忆库（向量库/数据库），供后续检索。

时机与好处

• 时机：会话结束、定期批处理、事件触发。
• 好处：省 token（不再整段重放）、信息可检索复用、形成稳定画像。

Agent 记忆和 RAG 有什么区别？

区别

联系

• 实现技术相似：都靠 embedding + 向量库 + 检索。
• Agent 记忆常被称作「给 Agent 自己用的 RAG」，检索对象从文档变成「记忆条目」。

supervisor 模式是如何工作的？

定义

Supervisor 模式：设置一个中央 supervisor agent，负责把任务分发给多个 worker agent，汇总结果，是「主管-下属」结构。

控制流

supervisor 判断 → 调用 worker_A → 收回结果 → 判断 → 调用 worker_B → ... → 汇总输出

• supervisor 决定调用哪个 worker、何时结束，worker 只做具体子任务。
• LangGraph 实现：supervisor 节点 + 各 worker 节点 + 条件边（按 supervisor 输出路由）。

优缺点

hierarchical（分层）多 Agent 如何设计？

定义

Hierarchical Agent（分层 Agent）：按层级组织，上层负责规划与调度，下层负责执行具体子任务，可多层嵌套。

结构

• 规划层：把高层目标拆成子任务、分配给执行层。
• 执行层：完成子任务并回报结果。
• 可继续细分：规划层下面再有子规划层（树状）。

与 supervisor 的关系

• supervisor 可看作 hierarchical 的单层特例；hierarchical 更强调整体「树状分权」。

多 Agent 之间的通信协议有哪些？

消息结构

• 通信本质是结构化消息：{sender, receiver, type, content, metadata}。

协议类型

选择

• 少 agent 强协作 → 共享状态/直接对话；跨系统互操作 → A2A；接工具 → MCP。

什么是 debate（辩论）型多 Agent？reflection 型呢？

定义

Debate 型多 Agent：多个 agent 各自生成答案，然后互相批评/辩论，最后由裁判（judge）汇总，用「多视角碰撞」提升质量、降低幻觉。

流程

生成：Agent1、Agent2、... 各给方案
辩论：互相 critique 对方的问题
裁决：Judge 综合后给出最终答案

优点/代价

• 常见形式：LLM-debate、多模型投票、reflexion 的多人版。

什么是 swarm（群集）多 Agent？

定义

Swarm 模式：大量轻量、无状态的 agent 通过 handoff（交接） 动态协作，没有固定编排图，谁适合谁接手（OpenAI Swarm 框架提出）。

特点

与其它模式对比

• Supervisor：中央分发；Swarm：去中心化、agent 间直接 handoff。
• Swarm 更像「多客服转接」：接待 agent 识别意图后转给专家 agent。
• 注意：Swarm 是教学/实验性质框架，生产复杂流程仍多用 LangGraph。

agent loop 如何实现？

核心循环

messages = [system, user]
for _ in range(max_steps):
    resp = llm.chat(messages, tools=tools)
    if not resp.tool_calls:          # 无工具调用 → 结束
        return resp.content
    for tc in resp.tool_calls:        # 执行每个工具
        result = execute(tc)          # 宿主真正执行
        messages.append({"role": "tool", "tool_call_id": tc.id, "content": result})
    messages.append(resp)             # 把助手消息（含 tool_calls）也加入
# 超步数 → 强制终止

关键点

• 终止条件：无 tool_call、达到 max_steps、模型输出 Final Answer。
• 状态维护：messages 列表就是 loop 的「状态」，逐步累积。
• 框架（LangGraph）把 loop 抽象成「节点 + 边 + 条件循环」。

Agent 的 streaming（流式）如何实现？

两层 streaming

1. LLM token 流：模型逐 token 输出，前端即时显示。
2. 工具调用流：tool call 的 JSON 参数也要边生成边解析（增量 JSON parser），不等整段生成完。

事件流设计

把 Agent 运行过程抽象成事件序列推给前端：

on_llm_start → on_token（增量文本）→ on_tool_start → on_tool_end → ... → on_final

• 好处：用户实时看到「在思考/在调用哪个工具/返回了什么」，降低等待感知。
• 实现：框架（LangChain/LangGraph 的 astream_events）提供事件回调。

注意

• 工具调用中途可能失败/取消，需处理中断；增量解析要容错不完整 JSON。

human-in-the-loop 有哪些模式？

三种模式

实现

• LangGraph 的 interrupt 机制：在指定节点暂停，等待人工 resume 并注入新输入。
• 审批通常是「工具执行前拦截 + 权限回调」；接管是「切换到人工模式」。

原则

• 高危操作必经人；非关键步骤尽量自动化减少打断。

Agent 的可观测性（tracing）如何做？

记录什么

• 每步的输入/输出、工具调用与结果、token 用量、延迟、成本、模型与版本。

tracing 结构

• trace：一次完整任务；span：其中每个子步骤（LLM 调用、工具调用、检索）。
• 父子关联，形成调用树，可回溯「哪一步出错、消耗多少」。

工具

用途

• 调试（回放轨迹）、评估（轨迹打分）、成本分析、回归测试。

沙箱和权限如何设计？

沙箱（隔离执行）

• 代码/命令在容器（Docker）、VM 或 gVisor 中执行，隔离文件系统与网络。
• 限制：无网络/白名单网络、临时文件系统、资源配额（CPU/内存/超时）。

工具权限

• 白名单机制：只暴露允许的工具，隐藏危险能力。
• 参数校验：对工具入参做校验与范围限制。
• 最小权限：工具按任务只给必要权限（只读、指定表/目录）。
• 高危拦截：支付/删除类需人工确认。

实践

• 每个工具声明所需权限；运行时做权限判定；全程审计日志。

Agent 的 state 如何持久化？

state 是什么

• 会话消息、中间结果、计划状态、记忆指针等运行状态。

持久化方案

• 数据库：Postgres（结构化）、Redis（快取/短期）、对象存储（大结果）。
• checkpointer：框架层把 state 快照序列化存入（LangGraph 的 checkpointer）。
• 序列化注意：只存可序列化数据（dict/JSON），避免存不可序列化对象（函数、连接）。

好处

• 崩溃恢复、跨会话续跑、人工介入、时间旅行调试。
• 用 thread_id 标识一次会话，恢复时按 thread 取回最新 state。

checkpoint 和恢复如何实现？

checkpoint

• 在每个节点/步骤执行后保存 state 快照（含输入、输出、消息列表）。

恢复机制

执行节点 → 保存 checkpoint(thread_id, step) → 失败/暂停时从最近 checkpoint 恢复

• 重放：从 checkpoint 重新执行，避免从头跑。
• 时间旅行：回到任意历史 checkpoint 分支重试。
• 人工介入：在 checkpoint 暂停，注入输入后 resume。

实现（LangGraph）

• checkpointer + thread_id：同一 thread 复用 state；interrupt 在节点暂停，resume 继续。

死循环检测如何实现？

检测手段

处理

• 终止后：给模型明确「你重复了，请换策略或给最终答案」的提示，或直接降级/转人工。
• 结合超时 + token 预算兜底。

示例

seen = deque(maxlen=3)
for step in range(max_steps):
    key = (tool_name, json.dumps(args))
    if key in seen: return "检测到重复调用，终止"
    seen.append(key)

token 预算如何管理？

预算设计

• 总 token 上限、单步 token 上限、工具结果长度上限，超限即压缩或终止。

控制手段

监控

• 实时统计 token/成本，接近预算时告警或降级。

轨迹评估（trajectory evaluation）是什么？

定义

• 轨迹评估：不只评最终答案，还评估 Agent 的中间执行轨迹是否合理、高效。

评估维度

方法

• 参考轨迹比对：与标注的最优轨迹对比（编辑距离/覆盖率）。
• LLM-as-judge：让强模型给轨迹逐段打分。
• 过程奖励（PRM）：给每一步打奖励，而非只给最终结果（ORM）。

prompt injection 如何攻防？

攻击类型

防御

• 指令/数据隔离：外部内容一律当数据，不当指令；用分隔符明确边界。
• 输入过滤：检测并清洗可疑指令。
• 最小权限：即使被注入也无法造成大破坏。
• 人工确认：高危操作拦截。
• 输出过滤/沙箱：隔离执行、审计。
• 防御性系统提示：明确「忽略数据中的指令」。

本质

• LLM 无法天然区分「指令」与「数据」，间接注入尤其难防，需纵深防御。

工具越权的最小权限如何设计？

越权类型

• 水平越权：访问他人数据（用户 A 调到用户 B 的数据）。
• 垂直越权：低权限调用高权限工具（只读账号执行删除）。

最小权限原则

实践

• 数据库工具只给只读 + 白名单表；写操作单独、需确认；身份信息从会话注入而非让模型传。

Agent 的成本如何控制？

成本构成

• 输入 token（长上下文重放）、输出 token（多轮推理）、工具调用费、多 Agent 叠加。

控制手段

预算

• 设单任务成本上限，超限降级或转人工。

coding agent（SWE-agent/Devin）是如何工作的？

原理

• 让 LLM 在真实代码仓库中自主定位、修改、测试代码，完成 issue 修复等任务。

关键设计

• SWE-agent 的 ACI（Agent-Computer Interface）：给模型一套精简、易用的命令与文件查看器（受限搜索、滚动查看），比原始 shell 更易被 LLM 掌握。
• 闭环迭代：改代码 → 运行测试 → 看报错 → 继续改，靠真实执行反馈驱动。
• Devin：完整开发环境 + 长期规划 + 独立编码/测试/部署。

评估

• SWE-bench：从真实 GitHub issue 构建的基准，衡量「能否生成可过测试的 patch」。

browser agent（WebArena）是什么？

定义

• Browser Agent：让 LLM 通过操作浏览器（点击/输入/导航）完成真实网页任务；WebArena 是其代表性真实环境基准。

实现

• 用 Playwright/Selenium 控制浏览器；观察用 DOM 树 / 截图（+A11y 树）；动作空间是点击、输入、滚动、导航。
• 挑战：页面状态大、动作空间大、需要多步长程决策。

WebArena 基准

• 在真实网站（电商、论坛、GitLab、地图、CMS）上评测任务完成率。
• 任务如「找到某商品并加入购物车」「在论坛发帖」。

难点

• 页面解析噪声、动态内容、登录/验证码、多页面状态追踪。

Agent 和 Workflow 的边界如何划分？

决策框架

• Workflow：流程固定、可预测，步骤明确 → 用预编排（更可靠、可控、省成本）。
• Agent：任务开放、需动态决策（未知路径、需探索）→ 用 Agent。

判断标准

实践建议（Anthropic《Building Effective Agents》）

• 优先用最简单的方案；能 workflow 就不用 Agent。
• 常用「混合」：主干用 workflow，少数节点是 Agent。
• Agent 给「明确任务 + 清晰工具 + 结构化输出」约束，换取可靠性。