框架对比

• LangChain：链、工具、Agent、模型适配、回调、向量库集成丰富，适合快速拼装。
• LangGraph：把 Agent 建模成状态图，适合多步骤、可恢复、可人工介入的流程。
• LlamaIndex：围绕数据连接、索引、检索、查询引擎和 RAG 编排展开。
• AutoGen：强调多智能体对话、角色分工、代码执行和协作式求解。
• CrewAI：Agent、Task、Crew、Process、Tool、Memory 的角色化任务协作抽象较清晰。
• Semantic Kernel：插件、函数、Planner、Kernel Memory，更贴近企业系统集成。

答题抓手

• 规划：任务拆解、路线选择、动态重规划。
• 工具：函数描述、参数 schema、权限、超时、重试、结果校验。
• 记忆：会话状态、用户画像、长期知识、外部数据库。
• 执行器：调度工具、处理异常、汇总结果、控制循环次数。
• 观测：trace、token、延迟、成本、命中率、失败原因。

常见技术

• Planning：任务拆分、依赖排序、动态重规划。
• Tool Calling：函数调用、API 调度、参数校验、错误恢复。
• ReAct：思考、行动、观察循环，适合信息查找和工具任务。
• Reflection：生成后复盘，检查遗漏、矛盾和失败原因。
• Self-check：格式检查、引用检查、单测/静态检查、事实核验。
• Multi-agent：角色分工、评审者、执行者、协调者。

工程落地

• 给工具设置白名单、速率限制、超时和幂等处理。
• 限制 Agent 循环次数，避免无限反思和成本失控。
• 关键动作做人审或二次确认。
• 用 trace 记录每一步输入、输出、工具结果和错误。
• 把评估器和执行器拆开，避免同一个模型自说自话。

具体案例

• 格式偏离：要求 JSON 却输出自然语言，用 schema 校验和修复重试。
• 越界回答：文档无证据却回答，用引用校验和拒答策略拦截。
• 工具乱选：需要查订单却调用知识库，加入工具路由器和参数校验。
• 遗漏约束：忘记预算、时间、权限，把关键约束放入结构化 state。

对策

• 把目标、边界、输出格式、失败条件写成显式 checklist。
• 把模型输出交给 verifier 检查格式、引用、权限和业务规则。
• 低置信度或校验失败时重试，重试仍失败则澄清或人工接管。
• 收集失败样本，迭代 prompt、few-shot、工具描述或 SFT 数据。

架构模块

• 模型：负责理解、规划、生成和工具选择。
• 状态：保存目标、约束、计划、工具结果和待办。
• 工具：外部 API、数据库、代码执行、MCP 服务。
• 记忆：短期上下文和长期可复用信息。
• 评估器：检查结果是否满足目标和约束。

LangGraph 写法

• 定义状态 schema：messages、plan、artifacts、errors。
• 节点负责单一动作：规划、工具执行、评估、总结。
• 边负责条件跳转：成功结束、失败重试、缺参澄清。
• 循环必须有最大步数、失败计数和人工接管出口。

常见模式

• 标准 ReAct：Thought/Action/Observation 循环，边查边做。
• ReAct + Function Calling：动作由函数 schema 约束，参数更稳定。
• ReAct + RAG：把检索作为工具，适合外部知识问答。
• Plan-and-Execute：先规划再执行，适合多步骤任务。
• Reflexion：失败后总结经验并重试，适合可验证任务。
• ReWOO：先生成工具调用计划，再批量执行和汇总，降低循环成本。

适用场景

• 信息查找：标准 ReAct 或 ReAct + RAG。
• 代码修复：Plan-and-Execute + 测试反馈 + 自检。
• 客服/工单：工具调用 + 权限控制 + 人工兜底。
• 长流程生成：计划、执行、评估、重试分离。
• 高风险动作：ReAct 只做建议，最终动作需确认。

两种形态差异

• 编排式：路径明确、节点可控、易测试、易审计，适合客服、表单处理、审批、内容流水线。
• Agent 化：模型自主规划和选工具，灵活性高，但要控制循环、权限、成本和失败恢复。
• 稳定性：编排式更稳定，Agent 化更依赖模型能力和工具描述质量。
• 可观测性：编排式能逐节点定位问题，Agent 化要依赖 trace 和中间状态记录。

节点/流程设计模板

• Start：接收用户输入、业务参数、会话 ID。
• Normalize：用 LLM 或代码节点抽取意图、实体、约束。
• Knowledge/RAG：按意图召回知识库，必要时做重排。
• Tool/API：调用插件、HTTP API、数据库或 MCP 工具。
• Condition：按置信度、权限、缺参情况分支。
• Review/End：生成答案、引用证据、触发人工兜底或结束。

定位差异

• LangChain：模型、Prompt、工具、Agent、链路编排。
• LangGraph：状态图、循环、人工介入、可恢复 Agent。
• LlamaIndex：文档接入、索引、retriever、query engine、RAG 数据层。
• 选型：复杂 Agent 流程偏 LangGraph，复杂数据/RAG 偏 LlamaIndex。

幻觉缓解

• 混合检索 + rerank + query rewrite。
• 答案必须引用证据，引用不足时拒答。
• 生成后做事实一致性和引用覆盖检查。
• 高风险答案走人工审核或工具验证。
• 评测集中加入文档外问题和相似干扰问题。

选型回答

• LangChain：快速接模型、Prompt、Tool、Retriever。
• LangGraph：有状态、多节点、循环、条件边、人工介入。
• LlamaIndex：文档接入、索引、检索和数据层抽象。
• 版本问题：如实说项目版本，并说明关注 Runnable/LCEL、包拆分和 LangGraph 独立化。

ACT / workflow 取舍

• 确定性强的业务流程优先 workflow，便于测试和审计。
• 需要动态选工具、动态补信息时再引入 Agent 循环。
• ACT/ReAct 类方法适合边观察边行动，但要限制步数和权限。
• OpenClaw/Harness 等前沿工具按任务成功率、可控性和接入成本评估。

RAG 常用

• DocumentLoader：加载 PDF、网页、Markdown、数据库等数据源。
• TextSplitter：按字符、token、递归规则或语义方式切 chunk。
• Embeddings / VectorStore：向量化和向量库检索。
• Retriever：封装 topK、过滤、multi-query、compression 等召回逻辑。
• OutputParser：把回答约束成 JSON、Pydantic schema 或固定格式。

Agent 常用

• Tool / StructuredTool：声明函数名、描述、参数 schema 和返回。
• Runnable：把 prompt、model、parser、retriever、tool 组合成可观测链路。
• MessagesPlaceholder：注入历史消息、scratchpad 或工具调用轨迹。
• Callback：记录 token、耗时、工具调用和错误。
• LangGraph：复杂 Agent 用状态图表达节点、循环、条件边和人工介入。

可以这样展开

• 先说清实际使用程度：生产、PoC、阅读源码、只了解概念。
• 说明差异化维度：是否偏 GUI/浏览器自动化、是否内置任务规划、是否支持工具市场。
• 说明工程评估：失败恢复、日志 trace、权限隔离、模型兼容、部署成本。
• 对比主流方案：LangGraph 的流程控制、AutoGen 的多 Agent、MCP 的工具协议化。

推荐回答模板

“我不会把 OpenClaw 当作纯 RAG 框架理解，而会从 Agent runtime 看它： 是否能稳定完成感知、规划、工具执行、反馈校验和恢复。真正落地时，我更关心任务成功率、 可观测性、权限控制和能否接入现有系统，而不是 demo 能否跑通。”

分类

• 短期记忆：当前对话、任务 scratchpad、工具调用结果、当前计划。
• 长期记忆：用户偏好、项目背景、历史决策、沉淀经验。
• 外部记忆：数据库、向量库、知识图谱、文件系统、业务 API。
• 语义记忆：事实知识，例如“用户使用 FastAPI + PostgreSQL”。
• 情景记忆：发生过的事件，例如“上次线上问题由索引缺失导致”。
• 程序记忆：操作流程，例如“发布前必须跑哪些检查”。

工程实现

• 写入前做筛选：只保存稳定、可复用、有业务价值的信息。
• 检索时做召回与排序：按任务相关性、时间、可信度、权限过滤。
• 设置过期和纠错：偏好可能变化，历史结论可能失效。
• 敏感信息要脱敏、加密、授权访问，不能把 Memory 当无限日志。

常用策略

• 滑动窗口：保留最近 N 轮，适合短任务，但容易丢早期约束。
• 摘要压缩：把历史对话变成状态摘要，适合长任务。
• 分层摘要：轮次摘要、阶段摘要、项目摘要逐级合并。
• 检索式上下文：历史入库，当前只召回相关片段。
• 结构化状态：用 JSON/YAML 存目标、约束、决策、待办、证据。

有效信息判断

• 是否影响最终答案或执行路径。
• 是否是用户明确约束、偏好或纠错。
• 是否是外部事实、代码结论、测试结果或错误信息。
• 是否可复用到后续步骤。
• 是否有时间敏感性和可信来源。

短期记忆设计

• Conversation：最近对话、用户明确指令、纠错。
• Task State：目标、子任务、当前步骤、阻塞点。
• Tool Results：工具输入输出、错误、测试结果、外部证据。
• Compression：上下文接近上限时压缩成结构化摘要。

长期记忆设计

• Profile：用户偏好、技术栈、输出风格。
• Project Memory：架构、接口约定、历史决策。
• Knowledge：文档、FAQ、代码片段、经验库。
• Metadata：来源、时间、权限、置信度、过期时间。

实现方案

• 短期：messages、scratchpad、state store、LangGraph state。
• 中期：任务清单、阶段摘要、topic stack、待办和约束。
• 长期：关系库/文档库 + 向量库 + 元数据过滤。
• 开源方案可参考 LangGraph persistence、MemGPT/Letta、Zep、LlamaIndex memory 等思路。

会话关联

• 维护主题栈：A 买鞋、B 吃饭，用户说“前面那件事”时结合主题和时间回溯。
• 对指代词先做 resolver，不确定就澄清，不直接用最近语义命中。
• 检索时融合向量相似度、时间衰减、实体匹配、会话线程和用户显式指代。
• 注入前去重、排序、截断，并标明“事实/偏好/推断/待确认”。

三层职责

• 用户层：语言偏好、输出风格、常用工具，跨项目复用。
• 项目层：架构约定、命令、测试方式、代码规范。
• 会话层：当前目标、已读文件、计划、错误和验证结果。
• 写入要区分稳定事实和临时状态，避免污染长期记忆。

团队使用与监控

• 规定哪些代码、日志、密钥不能上传或进入上下文。
• 要求 AI 产出必须过测试、review 和安全扫描。
• 监控延迟、上下文 token、失败率、误改率和回滚率。
• 长上下文下降时用检索、摘要、任务拆分和文件白名单缓解。

选型维度

• 长上下文实际有效利用率，而不只看标称窗口。
• 工具调用稳定性、JSON 遵循、推理能力和多模态能力。
• 吞吐、首 token 延迟、总成本、限流和私有化需求。
• 是否支持缓存、批处理、流式输出和审计。

保留策略

• 事实证据优先于模型推断。
• 用户显式约束优先于默认偏好。
• 最新纠错优先于历史结论。
• 可恢复状态优先于完整聊天记录。

离线索引

• 数据源：文档、网页、数据库、工单、代码仓库。
• 清洗：去噪、去重、权限字段、时间字段、元数据。
• 切分：按语义、标题、段落、代码结构切 chunk。
• 索引：向量索引、倒排索引、稀疏向量、图索引。

在线查询

• 查询理解：意图识别、实体抽取、query rewrite。
• 召回：dense、sparse、hybrid、多路召回。
• 重排：cross-encoder、LLM rerank、规则加权。
• 融合：RRF、按来源可信度加权、去重合并。
• 生成：带引用回答，无法回答时明确说明。

向量数据来源

• 原始文档：PDF、Word、Markdown、网页、产品手册、制度文档。
• 结构化表：数据库表、Excel、指标表、配置表，可转成行级或主题级文本。
• 日志/工单：故障日志、客服记录、历史处理方案，需脱敏和时间标注。
• 代码/接口：代码片段、API schema、注释、README、变更记录。
• 多模态产物：OCR 文本、图片 caption、表格 JSON、图表摘要。

具体切分策略

• 先按标题、章节、段落、列表、表格、代码块等结构切。
• 再按 token 窗口控制长度，常见候选从 300-800 tokens 起测。
• 重叠一般从 10%-20% 或 50-150 tokens 起测，避免跨段信息断裂。
• 每个 chunk 记录文档 ID、章节路径、页码、坐标、时间、权限、来源版本。
• 表格按行、列、主题或整表摘要多粒度索引，避免单元格脱离表头。

父子分块落地

• 父块：按章节、页面、完整小节或业务主题切，保留完整语境。
• 子块：从父块中按段落/窗口切小块，用于 embedding 和召回。
• 对齐：子块保存 parent_id、offset、页码、标题路径和原文范围。
• 召回：先召回子块，再回填父块或相邻窗口给生成模型。
• 去重：多个子块命中同一父块时合并证据，控制上下文长度。

减少语义割裂

• 固定长度切分前先识别标题、句子、段落和列表边界。
• 不要把定义和解释、表头和数据、问题和答案切开。
• 对跨段依赖加重叠窗口或相邻 chunk 拼接。
• 给 chunk 前置章节标题和必要上下文摘要。
• 用评测集调参，不迷信固定窗口大小；看 Recall@K、忠实度和上下文噪声。

多维查询改写

• 补全实体、时间、产品、版本、故障码等维度。
• 生成同义问法、关键词版、语义版和结构化过滤条件。
• 缺关键槽位时先澄清，而不是盲目检索。
• 改写要保留原问题，避免改错用户意图。

并行与融合

• 并行意图识别可降低总延迟，也能覆盖多个候选意图。
• 汇总时按置信度、业务优先级和证据命中决策。
• 融合可用 RRF、加权分数、来源可信度和去重规则。
• 最终 trace 要能解释每条证据来自哪一路召回。

性能优化

• 缓存热门 query embedding 和重排结果。
• 限制 topK 与 rerank 候选数，按场景调参。
• 向量召回、关键词召回和结构化过滤并行执行。
• 慢查询记录 query、过滤条件、索引、候选数和耗时。

收益评估

• A/B 对比 rerank 前后的命中率、正确率和延迟。
• 用 gold evidence 判断 topK 是否覆盖答案依据。
• 看答案引用是否更集中、更相关、更少幻觉。
• 成本超预算时可只对低置信度 query rerank。

多跳链路

• 问题分解：抽取实体、关系、约束和缺失槽位。
• 逐跳检索：第一跳找实体背景，第二跳找关系或证据。
• 状态维护：记录已证实事实、来源和下一步待查问题。
• 证据融合：按时间、来源、置信度和引用覆盖合并。
• 最终校验：答案每个关键结论都能回到证据。

延迟控制

• 只对复杂问题启用 Agentic RAG，简单问题走普通 RAG。
• 多路召回并行，rerank 只处理候选 topN。
• 缓存 query rewrite、embedding、热门证据和中间结论。
• 设置最大跳数、最大工具调用数和低收益早停条件。

运行与更新

• 离线：上传文件、解析、清洗、切块、embedding、写索引。
• 在线：意图识别、召回、重排、生成、引用校验、日志。
• 部署：Docker 镜像、环境变量、模型/API 配置、向量库连接。
• 更新：增量索引、版本化索引、灰度切换和回滚。

数据治理

• 游戏用户多时，先做脏词、广告、重复、灌水、敏感信息过滤。
• 训练/评测数据来自真实问答日志、人工标注、失败样本和业务知识库。
• embedding 微调适合术语、缩写、黑话多且通用 embedding 召回差的场景。
• 如果新 embedding 已能覆盖业务，优先评估替换或混合检索，不一定继续微调。

参数与部署

• HNSW 参数不能背死值，要基于数据量、维度、召回率、延迟和内存压测。
• Milvus 部署要考虑 standalone/cluster、对象存储、元数据、分片、分区和备份。
• 多租户知识库可按用户/行业分区，元数据过滤权限。
• 上线看 p95/p99 延迟、召回率、索引构建耗时和内存占用。

HyDE / RRF / rerank

• HyDE 先生成假想答案再检索，适合短 query 或语义缺失，但生成偏了会带偏召回。
• RRF 用于多路召回结果融合，通常在 rerank 前合并候选。
• rerank 通常放在融合后，对较小候选集精排，节省成本。
• 不直接全量 rerank 是因为成本高、延迟高，且 rerank 需要候选召回先覆盖答案。

处理链路

• 解析：PDF/Word/图片转结构化页面，保留页码、坐标、标题层级。
• OCR：识别截图、扫描件、图中标注，记录置信度。
• 表格：抽取单元格、表头、合并单元格和单位，必要时转 Markdown/JSON。
• 图片：生成 caption、实体、关系、图例说明，并保存原图引用。
• 索引：文本向量、BM25、表格索引、图片 caption 向量、多模态 embedding。
• 召回：按问题路由到文本、表格、图片或混合召回，再重排。

多模态增强

• 图表转摘要：趋势、峰值、异常点、坐标轴和单位。
• 图片转结构化事实：对象、位置、数量、状态、操作步骤。
• 版面增强：同页标题、脚注、图注、相邻段落一起入上下文。
• 答案约束：引用文档页码、图片 ID、表格行列，避免文档外扩写。

扫描件图片处理

• 先做页面分类：可抽文本、扫描图、表格密集、图文混排。
• 扫描件走 OCR/多模态 API，保存识别文本、坐标、置信度和原图引用。
• 低置信度区域可裁图重试，或用更强视觉模型做二次识别。
• 识别结果不要直接当事实，要带页码和 bbox 进入后续校验。

分页表格与缺失修复

• 跨页表格用 table_id、表头相似度、列数、列名、页序和 bbox 对齐。
• 第一页保留表头，后续页缺表头时继承父表头并记录来源。
• 缺失单元格用邻近行列、单位、格式规则和原图复核，不能凭模型编值。
• 最终同时保存 Markdown、JSON、原始截图和表格元数据，方便检索与溯源。

对齐信号

• 版面坐标：图片 bbox 与段落 bbox 的距离。
• 结构信号：标题、章节、图编号、表编号、caption。
• 语义信号：图片 caption 与相邻文本 embedding 相似度。
• OCR 信号：图中关键词与正文实体是否重合。
• 人工 gold set：用于校准规则、评估召回和训练对齐模型。

降成本方法

• 先用规则解决明显样本，只把模糊样本交给模型。
• 按置信度分桶，低置信度抽样人工审核。
• 用小模型做初筛，大模型只处理难例。
• 构建主动学习闭环，把错误样本回流到规则和训练集。
• 缓存 caption、OCR 和 embedding，避免重复计算。

处理策略

• 拒答：证据不足时明确说明，不编造。
• 澄清：问题含糊、实体不明、时间范围不明时追问。
• 检索扩展：query rewrite、多路召回、同义词、跨库检索。
• 工具 fallback：调用搜索、业务 API、工单系统或人工知识库。
• 人工兜底：高风险业务、低置信度答案进入人工审核。

幻觉控制

• Prompt 明确“只能基于证据回答”。
• 答案必须附引用，引用覆盖核心结论。
• 生成后做 entailment/一致性检查。
• 对数字、时间、地点、表格字段做规则校验。
• 记录无答案率、误答率、引用缺失率。

抽取字段

• 设备型号、部件、位置、版本、运行环境。
• 故障现象、错误码、日志片段、出现频率。
• 时间线：何时开始、是否复现、触发条件。
• 用户操作：重启、替换、升级、回滚、清理。
• 影响：是否停机、影响范围、严重等级。

工程做法

• 术语表 + 同义词表，把口语映射到标准实体。
• NER/关系抽取生成结构化 JSON。
• RAG 召回维修手册、历史工单和知识库。
• 低置信度字段主动追问，不猜设备或坐标。
• 用案例库验证诊断建议，输出证据和下一步检查。

图搜图

• 图片预处理、特征提取、向量归一化、ANN 检索。
• 相似度可用 cosine、dot product 或欧氏距离，关键是同一 embedding 空间。
• 结合分类、时间、地点、质量分过滤，避免只看向量相似。
• 评估 Recall@K、mAP、误召回和延迟。

实时交互

• 数字人用 VAD 判断用户是否说完，支持打断和流式 ASR。
• 用户停顿时不急着回答，可设置短等待窗口和增量理解。
• 摄像头场景用传统 CV 做实时检测，多模态模型做复杂理解和复核。
• 架构上分流式采集、事件检测、模型推理、TTS/渲染和低延迟缓存。

模板结构

• 明确任务边界和不可做事项。
• 把输入字段结构化，避免无关信息污染。
• 输出用 JSON/schema 或固定段落结构。
• 加入正反例，覆盖常见失败模式。

迭代方法

• 每次只改一个变量，保留版本和变更原因。
• 用离线集跑自动评测和人工抽检。
• 对线上失败样本归因，进入回归集。
• 指标变好但成本/延迟恶化时要做取舍。

指标定义

• Recall@K：分子是 top K 命中 gold evidence 的问题数，分母是可回答问题总数。
• 忠实度：分子是答案中可被证据支持的断言数，分母是答案全部关键断言数。
• 引用覆盖率：分子是有有效引用的关键结论数，分母是全部关键结论数。
• 拒答准确率：文档外问题中正确拒答的比例。
• 解析准确率：表格单元格、OCR 文本、图文关系与人工标注一致的比例。

LLM-as-judge 方案

• 问题集覆盖事实问答、表格计算、图表理解、文档外问题和边界问题。
• 给评测模型提供问题、答案、检索证据、标准答案和评分 rubric。
• 要求输出 JSON：正确性、忠实度、引用、遗漏、错误原因。
• 用人工 gold set 校准模型评分，计算与人工的一致率或 Cohen's kappa。
• 不同模型评测时固定 prompt、证据、温度和评分维度，避免口径漂移。

测试层次

• 单元：解析器、切分器、检索器、工具 schema、权限过滤。
• 集成：RAG 链路、Agent 工具调用、memory 写入和检索。
• E2E：从用户问题到答案、引用、操作结果全链路验证。
• 回归：每次 prompt、模型、索引、工具变更后跑固定集。
• 对抗：提示注入、越权请求、模糊实体、缺参、脏数据。

数据集构建

• 从真实日志抽样，去除隐私后人工标注。
• 按业务场景和难度分桶，避免只测简单题。
• 为每个问题标注 gold answer、gold evidence、允许拒答条件。
• 保留错误样本，形成 regression set。
• 线上监控无答案率、低分率、重试率和人工接管率。

不适合自动生成的代码

• 强依赖真实 DB/RPC/文件系统且无接口抽象。
• 大量时间、随机、并发、全局状态和单例副作用。
• 业务规则藏在配置、反射、动态执行或运行时上下文。
• 函数过长、职责混杂、输入输出不可观测。

Mock 边界

• 外部不可控依赖必须 mock 或 contract test。
• 核心业务逻辑不要过度 mock，否则掩盖真实集成问题。
• DB/RPC 用测试容器、桩服务、契约数据和事务回滚保证稳定。
• 质量指标包括断言密度、变异分数、flake rate 和缺陷发现率。

实现思路

• 源码/AST 插桩：可读性强，但要处理语法映射。
• 字节码插桩：语言运行时友好，常见于 JVM。
• 运行时 trace：侵入低，但映射和精度要校准。
• 计数器按文件、函数、行、分支 ID 聚合。

指标优化

• 优先提高关键业务分支，而非追求无意义覆盖。
• 关注异常、空值、边界、权限和并发路径。
• 结合 mutation testing 判断断言是否真的有效。
• 对生成测试设最低断言质量和稳定性门槛。

偏差分析

• 按时间、用户群、地区、设备、数值区间分桶比较误差。
• 看模型是否在长尾、异常值、冷启动样本上失真。
• 保留传统方法作为 baseline、兜底或校验器。
• 上线前做回放测试，上线后监控漂移和误差分布。

SFT 决策

• 多任务 SFT：泛化好，适合通用助手和多能力模型。
• 单任务 SFT：上限高，适合医疗、法律、函数调用等垂直任务。
• 任务冲突时分 adapter、分路由或分阶段训练。
• 评估要看任务指标、格式遵循、幻觉、拒答和泛化能力。

协议抽象

• Tools：模型可请求执行的动作，例如查库、发工单、读文件。
• Resources：可读取的上下文数据，例如文档、schema、日志。
• Prompts：服务端提供的可复用提示模板或工作流入口。
• Transport：常见为 stdio 或 HTTP/SSE 等传输方式。
• 消息：基于 JSON-RPC 风格请求、响应与通知。

工程价值

• 统一工具描述、参数 schema、返回格式和错误处理。
• 降低模型应用接入数据库、代码仓库、内部系统的重复成本。
• 便于权限控制、审计、隔离和观测。
• 让工具服务可以独立部署、测试和复用。
• 适合企业把内部能力封装为可控的模型上下文服务。

接口形态

• Tool 名称：动词 + 业务对象，例如 search_docs、create_ticket。
• 参数 schema：明确类型、必填字段、枚举值、分页、时间范围。
• 返回结构：状态、数据、引用来源、置信度、错误码。
• 资源：把文档、schema、日志作为 resources 暴露给模型读取。
• 提示模板：用 prompts 固化常见排障、摘要、检索工作流。

安全与可靠性

• 鉴权用 OAuth、PAT、服务账号或会话身份透传。
• 工具按最小权限设计，写操作需要显式确认或审批。
• 输入做 schema 校验、SQL/命令注入防护、路径白名单。
• 输出做脱敏、权限过滤和敏感字段裁剪。
• 网络失败可指数退避重试，业务失败不盲目重试。
• 记录 trace、调用人、参数摘要、结果状态和耗时。

封装内容

• 元数据：名称、描述、适用场景、版本、权限需求。
• 说明：执行流程、边界条件、质量标准。
• 资源：模板、示例、参考文档、脚本、资产。
• 工具：可调用 API、命令、MCP server、浏览器或文件能力。

选择与调用

• 先用短描述做候选召回，避免把全部说明塞进上下文。
• 匹配任务意图、输入类型、输出格式和权限边界。
• 命中后按需加载详细说明、脚本或模板。
• 执行时记录 trace，并在失败时给出可恢复路径。

信息分层

• 第一层：名称、描述、触发条件，用于候选召回。
• 第二层：Skill 主说明，包含核心流程和约束。
• 第三层：按需读取的参考文档、脚本、模板、样例。
• 第四层：执行产物、日志、验证结果。

为什么有效

• 降低 token 消耗。
• 减少无关指令干扰。
• 让模型先做“是否需要”的选择，再做“如何执行”。
• 复杂能力可维护为模块，不必塞进系统提示词。

核心思路

• 发现：通过 Agent Card 描述名称、能力、端点、认证和交互方式。
• 通信：使用标准消息和任务协议传递请求、状态和结果。
• 任务：创建、执行、取消、查询状态，支持长任务和异步更新。
• 产物：返回文档、结构化数据、链接、文件等 artifact。
• 治理：鉴权、审计、权限、速率限制和可信边界。

与 MCP 的区别

MCP 更偏“模型应用连接工具和数据源”，A2A 更偏“Agent 之间互相发现、委派任务和协作”。 一个 Agent 可以通过 MCP 调工具，也可以通过 A2A 把任务交给另一个专业 Agent。

额外收益

• 低成本适配领域表达、格式和分类边界。
• 多个 adapter 可按客户、任务、语言或场景切换。
• 不改基座模型，部署和回滚更轻。
• 训练更快，适合频繁迭代和小样本验证。
• 可与 RAG 互补：RAG 补知识，LoRA 补行为和风格。

落地评估

• 离线：准确率、格式遵循、拒答、幻觉率。
• 线上：人工接管率、用户满意度、延迟、成本。
• 风险：过拟合、灾难性遗忘、数据泄露、评测集污染。
• 回滚：adapter 版本可切换，保留基座模型路径。

后训接触怎么答

• 数据：原始数据可能是文档、工单、日志、对话，但训练前整理成 JSONL/messages 等结构化样本。
• SFT：让模型学习垂直领域问答、格式遵循、工具调用或拒答边界。
• LoRA/QLoRA：只训练 adapter，适合资源有限、快速试验和多版本切换。
• 偏好优化：当答案风格、拒答、安全性或工具选择需要对齐时再考虑 DPO/RLHF/GRPO。

参数怎么调

• 学习率：先小范围网格搜索；loss 震荡就降，收敛太慢可适当升。
• epoch：看验证集，不看训练集；验证集下降后变差说明过拟合。
• batch / grad accumulation：受显存限制，目标是稳定梯度和可接受吞吐。
• LoRA r/alpha/dropout：r 控制容量，alpha 控制 adapter 影响强度，dropout 抑制过拟合。
• target modules：常从 attention 的 q/k/v/o 或 MLP 模块试起，按任务收益和成本选择。

为什么不全量微调

• 全量微调显存、算力、训练时间和回滚成本高。
• 小数据场景容易过拟合，也更容易破坏基座通用能力。
• LoRA/QLoRA 只训练 adapter，适合快速试错、多行业多版本隔离。
• 只有数据量大、任务强绑定、预算足、需要深度改模型行为时才考虑全量。

大规模数据与行业 PDF 方案

• 几百万样本不一定更好，关键看去重、质量、覆盖、标签一致性和噪声率。
• 20 个行业 PDF 先解析、脱敏、切块、抽取术语/问答/拒答样本，再分行业采样。
• 优先做 RAG + 少量 SFT/LoRA；事实知识尽量放知识库，模型学习回答方式和边界。
• 评估按行业分桶，看准确率、幻觉率、拒答、格式遵循和行业间负迁移。

避免过拟合

• 训练/验证/测试严格隔离，保留线上真实回归集。
• 控制 epoch、学习率、LoRA rank/alpha，必要时加 dropout 和 early stopping。
• 清洗重复样本、模板化样本和低质量答案，避免模型背题。
• 同时看训练 loss、验证集指标、人工抽检和泛化样本。

显存不足

• 常见原因：模型太大、序列太长、batch 太大、optimizer state 和 KV/activation 占用高。
• 解决：QLoRA/量化、gradient checkpointing、梯度累积、降低 batch/seq length。
• 使用 ZeRO/FSDP、混合精度、CPU/NVMe offload 或多卡切分。
• 训练前估算显存，训练中监控 OOM、吞吐和显存峰值。

DPO 与 PPO

• DPO 输入偏好对：prompt、chosen、rejected，训练稳定、工程简单。
• DPO 损失可表述为让模型相对参考模型提高 chosen 相对 rejected 的 log prob 差。
• PPO 更灵活，可在线采样和多目标奖励，但训练复杂、稳定性要求高。
• PPO 优势是可优化不可微或组合奖励，例如工具执行成功、用户反馈。

奖励设计

• 结果奖励：答案正确、SQL 执行成功、工具返回满足目标。
• 过程奖励：工具顺序、参数合法、引用覆盖、无越权。
• 惩罚项：幻觉、格式错、越权、长回答、无效调用和重复调用。
• 奖励值先规则化、归一化，再用人工样本校准，避免 reward hacking。

模型对比维度

• 中文专业术语、长文档、数学/推理、代码、函数调用。
• 多模态 OCR/图表理解能力和结构化输出稳定性。
• 部署方式：API、私有化、量化、显存、吞吐和限流。
• 业务集 A/B：不要用单个 demo 决定模型。

Embedding 取舍

• LLM embedding 对长语义、跨语言、复杂 query 可能更好。
• BGE/M3 类模型工程成熟，适合本地化和高并发低成本。
• 专有名词、错误码、型号仍要配 BM25，不要只靠 embedding。
• 最终看 Recall@K、NDCG、延迟、成本和线上采纳率。

LSTM 细节

• 训练时输入通常是历史序列和标签，可能用 teacher forcing。
• 预测时只能用已知历史和模型上一步输出，容易误差累积。
• 权重在时间维共享，但不同层、不同方向的 LSTM 有各自参数。
• 预测值要和传统公式/规则值比较偏差，分析系统性误差和极端样本。

Transformer 基础

• 位置编码包括绝对位置、相对位置、RoPE、ALiBi 等。
• Encoder 偏理解输入，Decoder 偏自回归生成，Encoder-Decoder 适合翻译等任务。
• Dropout 训练时随机丢弃部分激活，降低共适应和过拟合；预测时关闭。
• Temperature 调整 logits 分布，越高越随机，越低越确定。

Python 侧

• FastAPI/Flask 提供模型服务和 Agent API。
• Pandas、PyMuPDF、OCR、向量库 SDK 做文档处理。
• asyncio/httpx 处理并发模型调用和工具调用。
• pytest + 评测脚本做离线测试。

Java 侧

• 线程池参数、队列、拒绝策略和上下文传递。
• 类加载机制、双亲委派、SPI、热加载风险。
• JVM 内存、GC、锁、并发容器和异步编排。
• Spring Boot 对接 AI 服务、权限、审计和业务系统。

慢查询优化

• 用 EXPLAIN 看 type、key、rows、Extra。
• 检查是否全表扫描、回表过多、排序临时表、索引失效。
• 优化 where/order by/group by、分页和 join 顺序。
• 必要时加联合索引、覆盖索引或拆分冷热数据。

索引与 MVCC

• B+ 树适合范围查询和排序；Hash 适合等值但不适合范围。
• 全文索引用于文本匹配，空间索引用于 GIS。
• MVCC 通过版本链和 read view 支持非锁定一致性读。
• 覆盖索引生效前提是查询列都来自同一索引且条件可利用。

并发与锁

• Lock 互斥，RLock 可重入，Semaphore 控制并发许可数。
• 锁解决共享资源竞争，风险是死锁、饥饿、优先级反转。
• 多机用分布式锁，需考虑过期、续租、时钟、幂等和 fencing token。
• 协程是用户态调度的轻量执行单元，线程由 OS 调度，进程资源隔离更强。

网络与运行时

• HTTPS 通过证书验证身份，握手协商密钥，后续对称加密传输。
• JVM 内存包括堆、栈、方法区/元空间、程序计数器和本地方法栈。
• Hash 要关注函数分布、冲突处理、扩容和一致性哈希。
• 长链接/短链系统用短码映射长 URL，存储映射、过期、风控和跳转统计。

Attention 基础

• Q 表示“我要找什么”，K 表示“我是什么索引”，V 表示“我提供什么信息”。
• Multi-head 让模型从不同子空间关注语法、实体、位置和关系。
• 长上下文瓶颈是 attention 复杂度高、成本高和有效注意力下降。
• 优化手段包括稀疏注意力、滑窗、KV cache、检索增强、摘要和分块。

SFT / RL 切入

• SFT 用高质量函数调用样本学习工具选择、参数和输出格式。
• PPO 常见 Reward Model 评分，Critic 估计价值函数降低方差。
• GRPO 可用组内相对奖励，减少单独 value model 依赖。
• Function Call 奖励包含结果奖励、参数合法、工具顺序和过程惩罚。

部署方式

• Docker 镜像固定依赖，K8s/裸机按 GPU 资源调度。
• 配置模型路径、tokenizer、量化方式、并发数、显存利用率。
• 灰度发布新模型，保留旧版本回滚。
• RAG 服务和模型服务解耦，方便单独扩容。

监控指标

• 请求量、成功率、错误码、首 token 延迟、总延迟、吞吐。
• 输入/输出 token、队列等待、GPU 利用率、显存、OOM。
• 模型质量：采纳率、拒答率、幻觉率、人工接管率。
• 成本：每请求 token 成本、GPU 小时成本和缓存命中率。

优化算法

• SGD 简单但震荡；Momentum 加速并抑制震荡。
• RMSProp 根据梯度平方滑动平均调整步长。
• Adam 同时用动量和自适应学习率，AdamW 解耦 weight decay。
• 调参重点看学习率、batch、warmup、梯度裁剪和验证集。

Linux 高频命令

• 文件：ls、find、du、tar、chmod。
• 文本：grep、awk、sed、head、tail。
• 进程：ps、top、kill、nohup。
• 网络：curl、netstat/ss、lsof、ping。

核心组件

• APIRouter：按业务域拆路由，便于版本化和模块管理。
• Pydantic：类型校验、默认值、嵌套模型、响应过滤。
• Depends：数据库 session、鉴权、配置、分页参数复用。
• Middleware：CORS、日志、请求 ID、耗时统计、限流。
• BackgroundTasks：发邮件、写审计、异步通知等轻任务。
• Lifespan：初始化连接池、模型、缓存，关闭时释放资源。

相关包

• uvicorn：ASGI server，本地开发和生产常用。
• sqlalchemy / sqlmodel：ORM、事务、数据库模型。
• alembic：数据库迁移。
• httpx：异步 HTTP 客户端和测试客户端。
• python-jose / pyjwt：JWT 处理。
• pytest：接口测试、依赖覆盖、异步测试。

完整流程

• 解析问题：时间、指标、维度、过滤条件、排序和聚合。
• schema linking：把业务词映射到表、字段、指标口径和枚举值。
• 生成 SQL：结合示例、库表说明、字段约束和 SQL 方言。
• 校验执行：AST/SQL parser 检查，只允许 SELECT，补 limit，阻断越权表字段。
• 结果解释：把查询结果转成业务语言，必要时提示口径限制。

多 Agent 状态设计

• 共享状态只放 query、候选 schema、约束、候选 SQL、校验结果和错误。
• 每个子 Agent 有私有 scratchpad，避免互相污染推理过程。
• Supervisor 只读取结构化产物做路由，不共享敏感中间链路。
• schema 不匹配时走澄清、同义词、指标字典或人工维护的指标层。

模块拆解

• Input Analyzer：解析题材、受众、时长、画风、平台规格。
• World/Character Bible：沉淀角色外貌、性格、关系、场景设定。
• Plot Planner：生成起承转合、冲突、反转和节奏。
• Storyboard Agent：拆镜头、景别、动作、对白和旁白。
• Prompt Builder：生成图像、视频、TTS、音乐提示词。
• Asset Generator：调用图像、视频、语音、字幕工具。
• Composer：合成画面、字幕、配音、转场和封面。
• Evaluator：检查剧情、角色一致性、画面质量、安全和平台规范。

编排流程

• 场景输入 → 需求解析 → 风格/角色设定。
• 剧情大纲 → 分集/分镜 → 台词和旁白。
• 分镜提示词 → 素材生成 → 素材一致性检查。
• 视频合成 → 自动评分 → 生成修改建议。
• 低分片段局部重生成，高分片段锁定，直到达到阈值或触发人工审核。

端到端步骤

• 识别意图：天气查询、穿衣建议、出行建议。
• 抽取槽位：地点、时间、天气类型、单位。
• 缺参追问：地点或日期缺失时询问。
• 地理编码：城市-国家-行政区-经纬度标准化。
• 调用 API：当前天气、小时级、未来预报、空气质量。
• 生成答案：附时间、地点、数据来源和不确定性。

地理知识处理

• 用地理编码服务处理同名城市和别名。
• 保留国家、省、市、经纬度、时区和语言。
• 歧义地点要追问，例如“Springfield”。
• 缓存热门城市映射，但定期更新。
• 不要让模型自由生成经纬度作为事实。

编排方式

• 简单链路用工作流节点和条件分支。
• 复杂链路用 LangGraph/状态机保存状态。
• 工具统一注册 schema、权限、超时和重试策略。
• 每步输出结构化 JSON，作为下一步输入。
• 写操作前必须用户确认。

服务多时工程化

• 服务目录：名称、能力、参数、返回、权限、SLA。
• 路由器：按意图、领域、权限选择工具。
• 编排层：状态、依赖、并发、补偿、回滚。
• 观测层：trace、耗时、错误码、调用成本。
• 评估层：工具选择准确率、任务成功率、人工接管率。

流程设计

• 获取位置：公司地址库、用户选择、地图定位。
• 门店查询：按品牌、距离、营业状态、配送范围过滤。
• 菜单查询：规格、库存、价格、优惠、配送费。
• 偏好匹配：口味、温度、糖度、预算、过敏源。
• 确认下单：订单摘要、支付方式、收货信息。
• 售后状态：订单查询、取消、异常反馈。

失败点与纠正

• 坐标歧义：返回多个候选地址，要求用户确认。
• 模型编造：所有坐标、价格、库存必须来自工具。
• 门店不可配送：扩大范围、换门店、提示原因。
• 库存变更：下单前重新校验菜单和价格。
• API 失败：重试、降级、保留当前购物车状态。
• 不确定性：明确说“不确定”，不要假装已定位。

PDF 路线

• 用 Chromium 渲染 HTML，等待图片、字体、图表加载完成。
• 设置 page size、margin、print CSS、分页和页眉页脚。
• 适合交付归档、排版一致、不要求二次编辑的报告。

Word 路线

• 结构化抽取标题、段落、表格、图片，再生成 docx。
• 图片要下载或转 base64，保留尺寸、标题和引用关系。
• 复杂 HTML 建议用模板化组件，不要直接转换任意 CSS。

项目表达

• 用户量增长时先定位瓶颈：模型调用、检索、数据库、队列、上传解析或前端推流。
• 模型选型看能力、成本、延迟、上下文、多模态、私有化和稳定性。
• 失败复盘看需求是否真实、数据是否足够、链路是否可测、指标是否闭环。
• 可复现性靠环境锁定、依赖清单、样例数据、启动脚本和回归测试。

前沿判断

• 关注官方文档、论文、GitHub、技术博客、产品更新和真实用户反馈。
• OpenClaw 这类 Agent 产品要看感知、规划、工具执行、恢复和观测能力。
• 新工具先问：是否降低成本、提升成功率、改善可控性或缩短交付周期。
• 工程师核心竞争力会转向问题定义、系统设计、验证能力和复杂工程落地。