Jerry｜知识索引

外观

agent开发

约 1824 字大约 6 分钟

2026-04-24

1. 一个典型的 Agent 通常包含哪些核心部分？

  1. 大脑： 即 大型语言模型（LLM），负责理解指令、逻辑推理和生成内容。
  2. 规划（Planning）： 包含任务分解（Task Decomposition）和自我反思（Self-Reflection），比如常见的思维链（Chain of Thought）。
  3. 记忆（Memory）： 分为短期记忆（上下文对话历史）和长期记忆（通常借助向量数据库存储的关键信息）。
  4. 工具与行动（Skills/Tools/Action）： 让大模型具备执行力的关键，通过调用 API 来获取实时数据或执行现实世界中的操作。

2. Agent 开发的三种范式？

  1. ReAct：思考（Thought）、行动（Action）、观察（Observation）循环。
  2. Plan-and-Solve：先规划，再执行。
  3. Reflection：在前两种的基础上加入反思和优化。

3. ReAct 在工程实践中通常会遇到什么常见问题？都是怎么解决的？

  1. 格式失控，大模型不按约定格式返回

    • 宽容解析（清洗结构化指令）
    • 异常捕获与自动踢回，一旦解析报错或参数不对，把异常捕获，丢回给大模型重新生成
    • 格式失控问题在现代原生支持 Tool Calling 的大模型中已经几乎不存在了

  2. 死循环，工具返回了找不到，但大模型不死心重复调用，导致 Token 疯狂消耗、超时

    • 设置最大循环次数
    • 哈希校验（如果发现大模型连续两次给出的动作和参数完全一模一样，直接拦截，并向大模型注入干预信息：Observation: 你已经用相同的参数执行过该操作，请尝试更换策略或使用其他工具）

  3. 工具幻觉、参数类型不匹配

    • 强类型约束，不仅告诉大模型工具是什么，怎么用，还告诉它参数的具体类型
    • 异常捕获与自动踢回，一旦解析报错或参数不对，把异常捕获，丢回给大模型重新生成

  4. 上下文爆炸

    • 动态记忆压缩：当历史上下文接近 Token 阈值时（如85%），触发一个后台任务，使用一个小模型对之前的“思考和行动”历史进行总结，用一段简短的摘要替换掉长篇大论的原始日志

4. 怎么评估一个 Agent 回答的质量？

1. 建立可观测性（Observability）

  • 接入 LangSmith、Langfuse 或 Phoenix 等可观测性工具。这些平台能将单次用户请求拆解为完整的调用树（Trace），记录下每一次 Prompt 组装、Tool 耗时、API 原始响应等。没有 Trace，就无法做有效评估。

2. 核心评估指标（Metrics）

  • 端到端任务成功率： 这是最核心的业务指标。比如，如果是一个订票 Agent，成功在数据库生成了正确的订单就是成功。
  • 工具选择准确率： 面对特定意图，Agent 是否选择了正确的工具集。
  • 参数提取准确率： 调用工具时，提取的参数类型和值是否符合规范。
  • 效率指标： 完成任务消耗的 Step（步数）和 Token 数量。步数过多意味着模型在“绕弯路”。

3. 引入 LLM-as-a-Judge（让大模型当裁判）

  • 写一个专门的裁判 Prompt，将 Agent 的完整 Trace 输入给裁判模型，让裁判根据你定义的 Rubric（评分标准表）打分。

5. LLM 回答质量不高，怎么判断是工具问题还是LLM幻觉问题？

通过后台轨迹三步曲：

  1. 看输入： LLM 给工具传的参数对吗？（不对 ➡️ LLM 幻觉/能力不足）。
  2. 看输出： 工具返回的真实数据包含能回答问题的正确信息吗？（不包含 ➡️ 工具/数据源问题）。
  3. 看整合： LLM 把正确的工具输出转化成最终回答时，发生扭曲了吗？（扭曲了 ➡️ LLM 幻觉/遵循指令能力差）。

判定为大模型问题的特征：

  1. 无中生有（幻觉）： LLM 尝试调用一个根本没有注册的工具。
  2. 参数捏造（幻觉）： 工具需要一个标准的 ISO 日期格式 2026-05-01，但 LLM 传入了 "明天"。
  3. 无视观察结果： 轨迹显示工具明明返回了正确的数据（Observation: 杭州明天 25度），但 LLM 在最后一步（Final Answer）中却根据自己过期的预训练记忆，回答成了“杭州明天 15度”。
  4. 过早得出结论： 任务需要多次调用工具拼接信息，但 LLM 在信息不全的情况下就强行终止了循环，给出一个模棱两可的答案。
  5. 陷入死循环： 连续多次传入相同的错误参数调用同一个工具。

判定为工具问题的特征：

  1. 返回垃圾数据： LLM 正确调用了 Search 工具，但由于搜索引擎 API 拉胯，返回的网页摘要全是不相关的广告内容。
  2. 接口超时或崩溃： Trace 显示 LLM 成功发起了 Tool Call，但本地代码 Timeout，或抛出了 NullPointerException。
  3. 返回值格式过于庞杂： 工具返回了高达 5 万 Token 的未经清洗的 JSON 源码。这种超长、噪音极大的上下文直接撑爆了 LLM 的认知窗口，导致 LLM 在后续推理中“失忆”或“发疯”。
  4. 工具描述存在歧义： 这是最隐蔽的工具问题。如果工具描述写得模棱两可，导致 LLM 不知道什么时候该用它。这本质上是工程上的 Prompt 没写好，不能全怪 LLM 幻觉。

6. 企业 Agent 如何做安全合规

输入与输出层（LLM 侧防火墙）：

  • 防范提示词注入：引入专门的意图拦截器（如 Llama Guard 这样的专职安全小模型），在把用户的输入交给核心业务大模型之前，先做一次安全审查。
  • 系统提示词边界加固：System Prompt 中写死严格的身份和边界，例如“你是...，无关问题必须直接回复‘超出服务范围’”。
  • 部署数据防泄漏（DLP）探针：对大模型的最终输出进行正则匹配和语义分析，强制拦截敏感信息（如身份证号、内网 IP、API密钥等）的出站。

工具与执行层（防越权与破坏）：

  • 遵循最小权限原则：不给大模型数据库 DDL 权限，内部 API 必须限定为只读状态
  • 强制人机回环：敏感操作必须用户确认
  • 防范SSRF攻击：若 Agent 拥有发起 HTTP 请求或搜索网页的工具，必须在网络层建立严格的白名单，防止探测内网架构

架构与审计层（权限隔离与追溯）：

  • 访问控制：Agent 的每一次执行都必须携带当前真实用户的身份 Token。不能让一个普通员工通过 Agent/RAG 读取到高管级别的私有文档。
  • 建立全链路可观测性：记录完整的执行轨迹（Trace），包括用户的原始输入、Agent 的思考决策过程、调用的工具名称、传入工具的具体参数以及最终回答。