概述
-
tool: 行动解决
-
memory：储存上下文
-
planning: 执行中动态调整
-
LLM
- system： 系统提示词，全局约束
- assistant: 模型自己
- user
-
agent
- 可自主规划复杂任务，调用工具，并把中间结果记录，经过多轮循环，最后返回答案的智能体
- 单次调用是开环，agent是闭环调用
- agent = llm + planning + memory + tools
- 自主
- 工具调用决定调用哪个工具，什么参数，循环什么时候结束
- 信息不完整时先澄清还是先假设再验证
- 失败时重试，换策略，或者人工介入（系统设计）
- 可控性
- 策略和边界：参数校验，human in the loop, token预算，step上限，输出校验，自主也是在约束空间内的决策
- 核心
- thought -> action -> observation -> ... -> final answer （闭环的感知，思考和行动循环）
- orchestrator驱动，解析模型输出，调用工具，并把中间结果记录，经过多轮循环，最后返回答案
-
agent逻辑的伪代码示例
def run_agent(user_goal: str, tools: dict, llm, max_steps: int = 8):
messages = [{"role": "system", "content": "你是可调用工具的 Agent。"},
{"role": "user", "content": user_goal}]
for _ in range(max_steps):
plan = llm.chat(messages) # 模型决定：结束 or 调用某工具
action = parse_tool_call(plan) # 从模型输出解析结构化动作
if action.name == "finish":
return action.args["answer"]
obs = toolsaction.name
messages.append({"role": "assistant", "content": plan})
messages.append({"role": "user", "content": f"工具结果：{obs}"})
return "超过最大步数，未完成。" -
chatbot：不强调自主规划和闭环，工具调用，适合闲聊
-
llm chain：规定死步骤，不自主，适合固定任务
-
agent: 自主，适合复杂任务
感知规划记忆工具和执行反思
-
感知（Perception）：把多模态输入（文本、文件、接口返回、页面结构等）转成模型可用的表示，并抽取任务相关状态。
-
规划（Planning）：把目标拆成子目标与步骤
-
记忆（Memory）
- 短期：当前会话上下文、工具轨迹
- 长期：用户画像、文档知识、向量库、图数据库等
-
工具（Tools）
- 对外部世界可执行的操作抽象：需有清晰 schema（名称、描述、参数 JSON Schema）。
-
执行（Action）：真正调用工具或触发环境变化，并处理超时、重试、幂等等工程问题。
-
反思（Reflection）：对失败或质量不佳的结果进行自省：纠错、换策略、生成检查清单（常与「自我批评 / 验证器」配合）
技术细节（todo）
-
感知常与结构化抽取、OCR、HTML 解析、日志解析 结合；关键是减少噪声进上下文。
-
规划常见实现：CoT / ReAct、Planner-Executor 双模块、树搜索（LATS）、任务图。
-
记忆工程要点：摘要压缩、引用溯源、记忆冲突解决、权限与隐私。
-
工具要点：最小权限、参数校验、错误信息回灌模型
-
反思可做成独立子调用：「列出本次推理的三处风险并修正」
-
agent的记忆设计
- 分层设计最常见：工作记忆（当前轨迹与关键结论）+ 会话记忆（摘要滚动）+ 长期记忆（向量检索/结构化库）。写入要区分「事实」与「推断」，并带时间戳与来源，便于更新与撤销
-
工具调用的schema
tools = [
{
"type": "function",
"function": {
"name": "search_kb",
"description": "在公司知识库中按关键词搜索",
"parameters": {
"type": "object",
"properties": {
"query": {"type": "string"},
"top_k": {"type": "integer", "default": 5}
},
"required": ["query"]
}
}
}
] -
避免工具调用间迷失
- 明确停止条件和最大步数
- 关键步骤强制验证（ut检查或者LLM检查）
- 维护todo和当前子目标
- 每步输出要求结构化
-
解决结果冲突
- 优先级原则（权威源》时间新》多源一致），让模型显式输出冲突说明，必要时触发人工
-
降低幻觉
- 强 RAG 溯源：所有事实性结论必须附带来源（文档 ID、段落、URL），无引用则不允许断言；检索结果为空时明确回答「未找到依据」，而不是凭参数记忆编造。
- 禁止无引用断言：在系统提示词中约定「先检索、后回答」的顺序，要求模型在输出中显式标注引用编号，便于人工与自动校验。
- 模板化答复：对高频、高风险问题（如政策条款、金额、时间）使用固定模板填充，减少自由生成带来的漂移。
- 置信度与兜底：让模型输出置信度或「不确定」标记，低于阈值时转人工或触发二次检索，而不是强行给出答案。
- 结果校验：对关键字段做规则校验（数值范围、枚举值、格式），校验失败则回灌错误信息让模型重试。
- 上下文治理：控制注入上下文的噪声与长度，优先保留高相关片段，避免无关内容干扰判断
- 可观测与回归：记录每次回答的检索命中、引用与人工反馈，建立幻觉样本集做回归测试，持续迭代提示词与检索策略。
-
agent场景
- 智能客服
- 代码助手
-
agent落地首先关注
- 安全合规：权限
- 可控性： 工具白名单
- 可观测性: 轨迹，指标，回放
-
agent难点
- 评估困难：过程指标，结果指标和人工抽检
- 可解释性： 关键步骤可回放，提供轨迹
- 成本控制：摘要、小模型路由、缓存、批处理工具
- 安全性：分层信任域、输出过滤、秘密不入模型上下文
- 幻觉：检索和验证约束
-
评估好坏
- 任务成功率，平均成本，工具错误率，用户满意度
- 静态数据集，仿真环境和线上环境
- 最大风险：错误放大，滥用工具 -》 最小权限，强验证，人在回路
- 防止prompt注入
- 工具层鉴权约束，结构化分割用户内容和指令，敏感操作二次确认，输出测数据检查
- 任务成功率，平均成本，工具错误率，用户满意度
常见问题
- ReAct 框架里三个字母代表什么？解决什么问题？
A： Reasoning + Acting：在生成中交替进行 推理（Thought） 与 行动（Action），并接收 观察（Observation）。它解决的是：模型仅「空想」容易偏离事实；通过 显式推理 + 工具反馈 把推理锚定在真实环境上 - 设计 Agent 的停止条件？
A： 组合使用：模型声明 finish、任务清单全部完成、达到步数/预算上限、超时、连续无进展检测、外部成功信号（如测试通过）。生产环境必须有 硬上限 防止死循环 - 工具描述（tool description）为什么非常重要？
A： 模型靠描述做 工具选择；描述不清会导致 选错工具、参数幻觉。好的描述包含：何时用、何时不用、参数含义、错误示例、返回格式。 - Q17：Memory 用向量库就够了吗？
A： 不够。向量检索擅长相似度，但弱于精确约束与关系推理。工程上常见 向量 + 关键词/结构化库 + 图谱（按需），并维护元数据与权限。 - 多 Agent 协作和单 Agent 多工具怎么选？
A：单 Agent 多工具：实现简单、延迟低，适合任务边界清晰。
多 Agent：角色分工、并行探索、对抗审查（如「批评者 Agent」）；但带来 协调成本与一致性 问题。
选型看 任务分解结构、组织边界、延迟与成本。 - 如何做「人在回路」又不打断体验？
A： 分级：低风险自动执行；中风险 异步审批；高风险 实时确认。产品上 预授权（例如仅本次会话可读某目录）、可撤销、默认最小权限。 - Agent 日志应记录什么？
A： 用户输入（脱敏）、模型原始输出、解析后的工具调用、工具返回摘要、耗时与 Token、版本号（模型与 Prompt）、追踪 ID，便于复盘与合规审计 - Agent 如何做版本管理与灰度？
A： Prompt/工具/schema 版本化；影子模式（只记录建议不执行）；金丝雀 用户群；关键指标对比（成功率、成本、违规数）；一键回滚。 - 上下文窗口越来越大，还需要外部记忆吗？
A： 需要。长窗口 ≠ 低成本，也不等于 可检索、可治理、可遗忘。外部记忆解决 跨会话持久化、结构化权限、版本与溯源；窗口内更适合 热工作集 - 如何测试 Agent？
A： 单元测工具、模拟环境、回归集（固定任务与期望轨迹范围）、对抗用例（注入、越权）、线上金丝雀；避免只测最终答案而忽略 过程正确性。