分类 AI 下的文章 - CorePlayers

2025年检索增强生成（RAG）最新进展与前沿技术 检索增强生成（Retrieval Augmented Generation, RAG）已从一个相对简单的"检索-生成"范式，演变为一个包含众多专业技术的复杂生态系统。2025年的发展趋势表明，RAG 的重点在于通过更高级的智能、适应性和上下文感知能力，来增强其流水线中的每一个组成部分。一、RAG 的演进历程最初的 RAG 系统采用固定的流水线作业：切块 → 向量化 → TopK检索 → 生成。然而实际应用中暴露了诸多问题，促使研究者将更复杂的推理能力嵌入 RAG 的各个阶段。2025年的演进可以概括为： Naive RAG：基础检索-生成两阶段 Advanced RAG：引入查询重写、重排序、上下文压缩 Self-RAG：系统评估自身中间步骤，动态调整策略 Agentic RAG：LLM 作为主动参与组件，自主规划检索策略 二、现代 RAG 的核心挑战1. 幻觉减少（Hallucination Reduction）确保 LLM 忠实地利用检索到的上下文进行生成仍是核心目标。CiteFix 和 DRAG 等技术专门针对这一问题，通过强制引用检索文档来约束生成行为。2. 知识陈旧性RAG 提供了无需完全重训练 LLM 即可注入最新知识的机制，但知识库的时效性管理成为了新的挑战。3. "Lost in the Middle" 问题LLM 倾向于关注文档的开头和结尾而忽略中间内容。先进的分块、重排序和上下文压缩技术致力于解决这一问题。三、先进的分块与嵌入策略语义分块：基于嵌入向量的语义相似性对句子进行分组，创建上下文感知的分块，取代传统的固定大小分块方法。文档结构感知分块：利用 Markdown 标题、章节、代码结构等确定分块边界，保留逻辑单元的完整性。Agentic 分块：让 LLM 自身根据语义含义和内容结构来决定最佳分块方式，最具实验性但也最有前景。四、鲁棒性 RAG：面向现实世界的设计2025年 RAG 研究的一个重要趋势是"面向鲁棒性的设计"。研究者正推动 RAG 从在干净数据集上追求准确率，转向在噪声数据、对抗性攻击、信息冲突等复杂条件下保持可靠性。代表性工作包括处理冲突信息的 Madam-RAG 和应对知识库投毒的 EcoSafeRAG。这种"防御性设计"对于企业采纳和高风险应用至关重要。五、总结与展望2025年的 RAG 正从简单的"检索-生成"管道演变为具备元学习能力的智能系统。未来的发展方向包括更强的自我适应能力、多模态检索集成以及更低的部署门槛。

多模态 RAG：图像检索增强生成的完整实践指南 传统 RAG（检索增强生成）主要处理文本数据，但在实际应用中，大量知识以图像、图表、PDF 扫描件等形式存在。多模态 RAG 将 RAG 的能力从文本扩展到图像，使得 AI 应用可以理解和检索视觉信息。本文将提供完整的技术实现方案。多模态 RAG 的架构设计一个典型的多模态 RAG 系统包含以下组件：1. 多模态嵌入模型：CLIP（Contrastive Language-Image Pre-training）是目前最主流的多模态嵌入模型。它可以将图像和文本映射到同一个向量空间，使得文本查询可以直接检索相关图像。OpenAI 的 CLIP ViT-L/14 模型在多项基准测试中表现最优，而开源替代方案如 Chinese-CLIP 在中文场景中更具优势。2. 多模态文档解析：PDF、PPT 等文档中的图文混合内容需要专门的解析器。Unstructured 库和 LlamaParse 是目前最成熟的方案，它们可以将复杂文档拆解为"文本块 + 关联图像块"的结构化片段。3. 多向量存储：支持向量搜索的数据库（如 Milvus、Weaviate）需要同时存储文本嵌入和图像嵌入，并维护它们之间的关联映射。完整流程1. 文档解析：将 PDF 中的文本和图像分别提取，记录它们在页面中的位置关系。2. 嵌入生成：文本块使用 text-embedding-3-large 生成嵌入，图像使用 CLIP 生成嵌入。3. 存储：将两种嵌入及元数据存入向量数据库，同时建立"文本块 ↔ 图像块"的映射表。4. 检索：用户查询时，使用相同的嵌入模型将查询转为向量，同时搜索文本向量和图像向量。5. 生成：将检索到的文本和图像 URL/描述一起传入多模态 LLM（如 GPT-4o），生成集成答案。

AI 应用开发Ⅱ 1. 项目中 RAG 流程是什么？标准 RAG 流程（五步）用户提问 ↓ ① Query 处理（改写/扩展/分解） ↓ ② 检索（Retrieval） ↓ ③ 重排序（Rerank） ↓ ④ 上下文拼装（Context Packing） ↓ ⑤ 生成（Generation） ↓ 最终回答各步骤详解步骤说明① Query 处理对用户原始问题做 Query Rewrite（改写为更适合检索的表述）、Query Expansion（扩展同义词）、Query Decomposition（复杂问题拆分为多个子问题）② 检索通过向量检索（Embedding 相似度）+ 关键词检索（BM25）混合召回，从知识库中找到相关文档块③ Rerank用 Cross-Encoder 等模型对召回结果做精排，过滤掉低相关性内容，保留 Top-K④ 上下文拼装将筛选后的文档块按一定策略拼装进 Prompt，加入来源标注⑤ 生成LLM 基于检索到的证据生成回答，要求"只根据证据回答，无证据就说不确定"面试回答模板我们项目的 RAG 流程是：首先对用户 Query 做改写和扩展，然后通过混合检索（向量 + BM25）从知识库召回相关文档，再用 Reranker 做精排，最后把筛选后的上下文拼入 Prompt 让 LLM 生成回答。同时会要求模型只基于检索到的证据回答，没有匹配就明确告知不确定。2. RAG 切块太小导致上下文语义断裂，如何处理？问题本质切块（Chunk）太小会导致：一句话被拆成两块，单独看每块都不完整，检索到的内容丢失上下文，模型无法理解完整语义。解决方案（五种）方案说明① 增大切块大小将 chunk_size 从 256 提升到 512-1024 tokens，overlap 从 50 提升到 100-200 tokens② 递归切分不按固定字符数切，而是按语义边界递归切分：先按章节 → 段落 → 句子，优先在大边界处断开③ 滑动窗口 + 重叠相邻 chunk 之间保留一定比例的重叠（overlap），确保边界信息不丢失④ 父子块策略（Parent-Child）小块用于检索（精准匹配），命中后返回其所在的大父块给模型（保留上下文）⑤ 语义切分用 Embedding 计算相邻句子的语义相似度，在相似度骤降处切分，保证每块语义完整推荐方案：父子块策略文档 ├── 父块 A（1024 tokens）← 检索命中后，把整个父块送给 LLM │ ├── 子块 A1（256 tokens）← 用于向量检索 │ ├── 子块 A2（256 tokens） │ └── 子块 A3（256 tokens） └── 父块 B（1024 tokens） ├── 子块 B1（256 tokens） └── 子块 B2（256 tokens）用小块做精准检索，用大块保留上下文。兼顾检索精度和语义完整性。3. 文档指代消解如何做？问题本质文档中常见指代现象，例如："该公司2025年营收增长30%。其净利润也大幅提升。" — "其"指代"该公司""张三负责前端开发。他使用了 React 框架。" — "他"指代"张三"如果直接切块，"其净利润大幅提升"单独拿出来不知道"其"是谁，检索时也无法通过"其"匹配到"该公司"。解决方案方案说明① 预处理阶段做指代消解在文档入库前，用 LLM 或 NLP 工具（如 spaCy、HanLP）识别代词并替换为实际实体。"其净利润" → "该公司净利润"② 扩大上下文窗口切块时保留足够上下文，让代词和它指代的实体在同一块内③ 检索时做 Query 扩展用户问"该公司利润"时，扩展为"该公司 该公司利润 净利润"，提高召回率④ 元数据标注在每个 chunk 上附加文档标题、章节标题、实体标签等元数据，辅助消解面试回答模板指代消解主要在文档预处理阶段做。入库前用 LLM 或 NLP 工具识别代词并替换为实际实体，比如"其"替换为"该公司"。同时配合父子块策略，确保切块时保留足够上下文，让代词和指代对象在同一块内。4. LangChain 中 Handoff 如何设计流程流转？Handoff 是什么Handoff（交接）是 LangGraph 中多 Agent 协作的核心机制，指一个 Agent 将任务控制权交给另一个 Agent。设计模式模式一：条件路由（Conditional Routing）from langgraph.graph import StateGraph def router(state): """根据当前状态决定下一步由谁处理""" if state["intent"] == "code": return "coder_agent" elif state["intent"] == "research": return "researcher_agent" else: return "general_agent" graph = StateGraph(AgentState) graph.add_node("planner", planner_agent) graph.add_node("coder_agent", coder_agent) graph.add_node("researcher_agent", researcher_agent) # 条件边：planner 根据意图路由到不同 Agent graph.add_conditional_edges("planner", router)模式二：Tool-based Handoff每个 Agent 作为一个 Tool 暴露给其他 Agent：# Agent A 把 Agent B 封装成工具 tools = [ Tool( name="delegate_to_coder", func=coder_agent.run, description="将编码任务交给 Coder Agent" ), Tool( name="delegate_to_reviewer", func=reviewer_agent.run, description="将审查任务交给 Reviewer Agent" ) ]模式三：Supervisor 模式由一个 Supervisor Agent 统一调度：Supervisor ├── 判断任务类型 ├── 分派给对应 Agent ├── 收集结果 └── 决定是否需要进一步处理面试回答模板LangChain/LangGraph 中的 Handoff 主要有三种设计：条件路由通过状态判断直接跳转到对应 Agent；Tool-based Handoff 把每个 Agent 封装成工具供其他 Agent 调用；Supervisor 模式由一个主 Agent 统一调度。生产中常用 Supervisor 模式，因为 Harness 可以在 Supervisor 层做预算控制、权限校验和失败处理。5. 主流 Agent 架构你是如何理解的？六种主流架构架构核心思想适用场景ReAct思考 → 行动 → 观察 → 循环通用任务，最经典Plan-and-Execute先规划完整计划，再逐步执行长任务、复杂任务Router先分类意图，再路由到对应处理链多能力分发Workflow + Agent固定流程中嵌入局部自主决策线上业务最常用Supervisor主 Agent 拆解任务，分派给子 Agent多 Agent 协作ReflectionAgent 生成后自我反思、修正需要高质量输出ReAct 架构图用户提问 → Thought（思考下一步）→ Action（调用工具）→ Observation（观察结果）→ Thought → ... → 最终回答Plan-and-Execute 架构图用户提问 → Planner（生成计划：Step1, Step2, Step3）→ Executor（逐步执行）→ Replanner（根据结果调整计划）→ 最终回答核心理解Agent 架构的本质是控制流的设计。ReAct 是最简单的循环控制；Plan-and-Execute 把"想"和"做"分离；Router 做意图分发；Supervisor 做任务编排。生产中往往不是单一架构，而是混合使用：顶层用 Supervisor 编排，子任务用 ReAct 或 Plan-and-Execute 执行，固定环节用 Workflow 保证稳定性。6. 最新技术（Harmes Agent、OpenClaw、Skills）Harmes Agent（Multi-Agent Harness）参考上一篇笔记《生产级Multi-Agent-Harness设计全拆解》：Agent 的"操作系统"，负责编排、调度、记忆、状态、工具治理、预算控制、可观测性核心原则：Agent 负责局部智能，Harness 负责全局控制五大模块：架构编排、工具治理、状态与记忆、评估体系、成本控制OpenClaw（Claude Code / Cursor 底层架构）OpenClaw 指的是 AI Coding Agent 的底层执行框架，核心特点：特性说明工具调用Agent 通过调用 Read、Edit、Bash、Grep 等工具操作代码库上下文管理自动压缩历史对话，保留关键信息权限控制工具调用需要用户授权（allowlist / dangerously-skip-permissions）多模型路由不同任务使用不同模型（Haiku 做快速判断，Opus 做复杂推理）Skills（技能系统）Skills 是 Agent 能力的模块化封装：Skill = 触发条件 + 执行逻辑 + 输出格式每个 Skill 是一个独立的能力单元（如"搜索网页"、"读取文件"、"运行测试"）Agent 根据用户意图动态加载合适的 Skill解决了"所有能力塞进 System Prompt 导致上下文爆炸"的问题面试回答模板最新的技术趋势是把 Agent 做成工程化的生产系统。Harness 是多 Agent 的运行时底座，负责编排、记忆、成本、安全。OpenClaw 是 Coding Agent 的执行框架，通过工具调用操作代码库。Skills 是能力的模块化封装，按需加载而非全量注入 System Prompt。7. OpenClaw 如何设置 Memory？Memory 分层设计层级存储内容生命周期存储位置短期记忆最近几轮对话、当前任务状态会话内上下文窗口长期记忆用户偏好、项目结构、历史决策跨会话文件系统（如 CLAUDE.md、memory/ 目录）摘要记忆旧对话的压缩摘要跨会话文件系统OpenClaw/Claude Code 的 Memory 实现~/.claude/ ├── settings.json # 用户配置 ├── projects/ │ └── / │ └── memory/ # 长期记忆文件 │ ├── user_preferences.md │ ├── project_context.md │ └── MEMORY.md # 记忆索引设置方式手动设置：用户说"记住 XXX"，Agent 写入 memory 文件自动设置：Agent 在交互中自动提取高价值信息写入 memory读取方式：每次对话开始时自动加载 MEMORY.md 索引，按需读取相关记忆文件面试回答模板OpenClaw 的 Memory 分三层：短期记忆在上下文窗口中，保留最近几轮对话；长期记忆以文件形式存储在磁盘上，比如 CLAUDE.md 和 memory 目录；摘要记忆是旧对话的压缩版。每次对话开始时加载记忆索引，按需读取相关记忆文件。用户可以手动让 Agent 记住某些信息，Agent 也会自动提取高价值信息写入。8. OpenClaw 没有向量数据库是如何查询的？核心答案：基于文件系统 + Grep/Glob + LLM 理解OpenClaw（Claude Code）不使用向量数据库，而是用以下方式定位信息：方式说明Grep（关键词搜索）用 ripgrep 在代码库中搜索关键词、函数名、变量名Glob（文件模式匹配）用 glob 模式查找文件，如 **/*.py、src/**/*.tsRead（读取文件）直接读取文件内容，让 LLM 理解目录结构探索先 ls 看目录结构，再逐层深入LLM 推理根据已有信息推理"下一步应该看哪里"为什么不需要向量数据库场景向量数据库的优势OpenClaw 的替代方案语义搜索理解"用户登录功能"能匹配到 auth.pyLLM 本身就理解语义，可以直接推理出应该看哪个文件跨文件关联自动建立文件间语义关系Agent 通过多轮工具调用逐步建立关联模糊查询"那个处理支付的函数"Grep 搜 payment、pay、charge 等关键词关键洞察向量数据库解决的是无 LLM 时的语义检索问题。当 Agent 本身就有一个强大的 LLM 作为"大脑"时，它可以自己推理"应该去哪里找什么"，用 Grep/Glob/Read 就够了。LLM 本身就是最好的"语义搜索引擎"。9. Cursor 中没有向量数据库，是如何定位到你要修改的位置？Cursor 的定位机制用户输入："给登录函数加上错误处理" ↓ ① LLM 分析意图 → 需要找到 auth/login 相关文件 ↓ ② 用 Grep 搜索关键词：login、auth、sign_in ↓ ③ 用 Glob 搜索文件模式：**/*auth*、**/*login* ↓ ④ 读取候选文件内容 ↓ ⑤ LLM 理解代码结构，确定具体函数位置 ↓ ⑥ 生成修改方案，调用 Edit 工具修改运行时 Bash 文件内容当 Cursor/Claude Code 执行 Bash 命令时，通常包含：# 搜索文件 find . -name "*.py" | grep auth # 或 grep -r "def login" --include="*.py" . # 读取文件 cat src/auth/login.py # 运行测试 python -m pytest tests/test_auth.py # Git 操作 git diff git add src/auth/login.py核心答案Cursor 不需要向量数据库，因为 LLM 本身就是语义理解引擎。它通过 Grep/Glob 快速定位候选文件，再通过 LLM 理解代码结构精确定位修改位置。这比向量数据库更灵活，因为 LLM 可以根据上下文动态调整搜索策略。10. Linux 如何找文件？常用命令命令用途示例find按条件递归搜索文件find /path -name "*.py" -type flocate基于数据库的快速搜索locate "*.py"grep搜索文件内容grep -r "function_name" /pathwhich查找可执行文件路径which pythonwhereis查找二进制、源码、手册whereis nginxls + 通配符列出匹配的文件ls /var/log/*.logfind 高级用法# 按名称查找 find . -name "*.py" # 按类型查找（f=文件，d=目录） find . -type f -name "*.py" # 按大小查找 find . -size +100M # 按修改时间查找（7天内修改的） find . -mtime -7 # 组合条件 find . -name "*.py" -mtime -7 -size +1k # 执行操作（找到后删除） find . -name "*.tmp" -exec rm \;面试回答模板Linux 找文件主要用 find 命令，支持按名称、类型、大小、时间等条件搜索。快速定位用 locate（基于数据库），搜索文件内容用 grep。生产环境中 find -exec 配合其他命令可以实现批量操作。11. AI 生成后上传到云端，如何提高用户使用效率？问题本质AI 生成内容后需要上传到云端，如何让用户更快、更省地完成这个过程。优化方案层面优化策略说明生成阶段流式输出（Streaming）用户不用等全部生成完，边生成边看到结果生成阶段增量生成只生成变化部分，不重新生成全部内容上传阶段增量上传只上传变化的文件/内容，不传全量上传阶段压缩传输对文本/代码做 gzip 压缩后再上传上传阶段并行上传多个文件并行上传，提升吞吐上传阶段断点续传大文件支持分片上传，失败后从断点继续部署阶段边缘部署就近接入 CDN/边缘节点，减少网络延迟部署阶段预热缓存高频访问内容预加载到缓存体验阶段预览功能上传前让用户预览/确认，减少无效上传体验阶段后台上传上传过程不阻塞用户操作部署优化（回答面试官可能想问的）优化点说明模型推理优化用 vLLM/TensorRT-LLM 加速推理，降低首 Token 延迟模型量化INT8/INT4 量化减少显存占用，提升吞吐批处理多个请求合并推理，提升 GPU 利用率异步架构生成任务放入消息队列，异步处理，用户轮询/WebSocket 获取结果CDN 加速静态资源走 CDN，API 走就近节点面试回答模板主要从三个层面优化：生成阶段用流式输出和增量生成，让用户不用等；上传阶段用增量上传、压缩传输、并行上传减少耗时；部署阶段用边缘节点、预热缓存降低延迟。如果是模型推理场景，还可以用 vLLM 加速推理、量化减少显存占用、异步架构避免阻塞用户。总结：面试核心考点考点涉及题目核心知识RAG 工程Q1-Q3完整流程、切块策略、指代消解Agent 架构Q4-Q6Handoff 设计、主流架构、最新技术趋势AI Coding AgentQ7-Q9Memory 设计、无向量数据库的检索方案工程基础Q10Linux 文件操作系统优化Q11流式输出、增量上传、部署优化

从零设计生产级 Multi-Agent Harness 核心观点真正决定 Multi-Agent 系统能否落地的，不是更强的模型或更精妙的 Prompt，而是背后那个常常被忽略的运行时底座——Multi-Agent Harness（多智能体执行框架）。一、Harness 是什么定义Multi-Agent Harness 指的是把多个 Agent 的能力、工具、状态、通信、编排、监控统一收束在一个运行时之内的框架。与相关概念的区别概念解决的问题Harness 的额外职责Prompt怎么让模型理解任务Harness 解决"怎么让模型可靠地完成任务"Orchestrator（编排器）顺序问题Harness 还要解决资源、记忆、成本、安全、可观测Agent Framework（LangGraph、AutoGen）提供积木Harness 是把积木拼成生产建筑的工程方案类比Prompt 是台词，Agent 是演员，工具是道具，模型是大脑，而 Harness 是整个舞台的导演、灯光、调度系统、安全规章和票务系统。二、架构编排：Agent 出主意，Harness 拿决定核心原则Agent 负责局部智能，Harness 负责全局控制。常见失败模式让 Planner Agent 自己决定调用哪个 Agent、是否继续、是否重试——短期灵活，长期危险。因为大模型没有天然的成本意识、并发意识、权限意识、全局一致性意识。Orchestrator 独占的五项决策权决策权说明任务生命周期每个任务从创建、规划、执行、审查、完成、失败，都要有明确的状态机执行计划裁决计划可来自静态 DAG 或 Planner Agent，但一旦生成必须由 Orchestrator 接管，判断每一步是否能跑、是否并行、是否超预算Agent 路由结合任务类型、Agent 能力、权限、历史质量评分进行路由失败处理某个 Agent 失败后是重试、降级、跳过还是终止，不能让出错 Agent 自己说了算硬终止条件必须有 max_steps、max_tokens、max_duration、max_tool_calls 四道硬闸声明式计划 vs 命令式调用命令式：直接 await researcher.run(...) — 把方向盘交给了 Agent声明式：Planner 输出声明式计划 — Harness 可以介入重排顺序、并行优化、拒绝某些步骤、执行前做安全审查别让 Agent 开车，让 Agent 当导航。三、工具治理：Tool Registry 是 Agent 的安全边界核心理念工具不是函数调用，而是生产资源的对外授权点。你给 Agent 一个工具，等于给它一把权限钥匙。Tool Registry 九项元信息元信息说明工具名称唯一标识工具描述给 LLM 看的说明输入参数 JSON Schema用于校验允许调用的 Agent 列表RBAC 权限控制调用超时与速率限制防滥用风险等级低/中/高是否需要人工确认高风险操作必须确认输出结果结构结构化定义审计日志策略保存什么、保留多久、谁能看落地建议哪怕只有 3 个工具，也从第一天起强制走 Tool Registry。先有规矩，后扩规模。工具治理不是装饰层，而是结构层。如果没有统一入口，系统会迅速演化成一团"散落的特权代码"，再想收回来代价极高。四、状态与记忆：记住该记的，忘掉该忘的记忆的四种典型失败失败类型表现记得太少每次都像第一次，无法复用经验记得太多上下文膨胀，检索噪声大，成本爆炸不分层临时数据和长期知识混在一起不遗忘过期信息长期污染决策状态 vs 记忆 状态（State）记忆（Memory）定义当前任务运行所需的数据跨任务复用的经验和知识生命周期短长关注点一致性相关性状态分层层级说明Working State当前步骤的临时上下文，任务结束即丢Session State一次会话里多个 Agent 共享的信息，放 Redis，设 TTLExecution Log不可变执行日志，用于审计、回放、评估记忆分层类型说明示例Episodic Memory（事件记忆）踩过的坑、用户偏好、某类问题处理经验"用户偏好 Python"Semantic Memory（语义记忆）领域概念、业务规则、工具约束"该接口有速率限制"注入时机（Retrieval Timing）模式优点缺点任务前自动注入简单稳定费 Token按需检索省钱Agent 可能忘记调用混合模式（推荐）前置注入少量高置信记忆 + 提供 memory_search 工具供 Agent 主动调用—遗忘机制（Memory Forgetting）记忆不是仓库，而是花园。需要定期修剪。基于访问频次、创建时间、重要性、最近使用计算保留分数：低分记忆 → 直接删除中分记忆 → 压缩为摘要高分记忆 → 保留原文五、评估体系：不要只看答案，要看轨迹为什么只看最终答案不够最终报告对了，但中间用了未授权的数据源最终代码能跑，但 Agent 调用了十几次无意义工具最终回答完整，但关键事实来自错误检索某次结果成功，只是因为重试撞上了正确答案四层评估体系层级名称评估内容第一层Component Eval（组件评估）单 Agent 是否选对工具、参数是否合规、输出是否符合角色职责第二层Trajectory Eval（轨迹评估）步骤是否必要、顺序是否合理、是否重复调用、是否陷入循环。Multi-Agent 最大的创新点第三层Task Completion Eval（任务完成度）是否满足用户目标、是否覆盖必要信息、是否存在事实错误第四层End-to-End Eval（端到端业务效果）用户是否采纳、人工返工率、处理时长、单位任务成本LLM-as-Judge 的局限适合：评估表达完整性、推理连贯性、总结质量等开放式输出不适合：事实正确性、代码可运行性、SQL 结果、权限合规——应优先用确定性检查成熟 Eval 必然是混合的单元测试检查代码 Schema 校验结构化输出 规则引擎检查安全约束 检索对齐校验引用来源 LLM-as-Judge 评开放式表达 人工抽检校准 Judge 偏差 线上反馈验证业务效果Eval 必须进入 CI每次改 Prompt、换模型、加工具、调参数，都要跑回归。Prompt 就是代码，工具 Schema 就是接口，执行轨迹就是日志，Eval 就是测试体系。六、成本控制：Token Budget 是生命线为什么 Multi-Agent 烧钱每个 Agent 都有 System Prompt每个 Agent 都需要上下文工具结果会被塞回模型Planner 生成计划 → Worker 执行步骤 → Reviewer 审查输出失败后还要重试多轮协作让历史不断复制膨胀策略一：Model Routing（模型路由）任务类型模型选择分类、摘要、格式转换小模型即可复杂推理、最终合成强模型高风险审查强模型 + 规则校验双保险低价值重试禁止使用高价模型目标不是一味省钱，而是在质量和成本之间找到可控平衡。策略二：Context Compression（上下文压缩）保留最近几轮原文 + 把更早历史压缩成结构化摘要摘要中只保留：关键事实、决策、未解决问题、工具结果引用注意：事实型任务必须保留原始引用，合规型任务关键证据不可压缩策略三：Budget 分级降级区间策略绿区（>50%）正常执行黄区（20%–50%）压缩上下文红区（5%–20%）切小模型 + 跳过 CoT熔断区（<5%）强制收束，返回 partial result关键监控指标单任务 Token 总量单 Agent Token 占比工具结果 Token 占比重试 Token 占比不同路由策略下的成本与成功率预算熔断次数单位业务结果成本（每完成一个合格任务多少钱）当你能精准回答最后一项时，Agent 系统才真正进入了可运营阶段。七、MCP 工具接入：标准化是趋势，但不能裸奔MCP 解决的核心问题MCP 之于 AI 工具，如同 USB-C 之于充电接口。工具一次实现，所有支持 MCP 的 LLM 应用都能调用。MCP 对 Harness 的三点意义快速扩展能力：通过 MCP Server 一键接入文件系统、数据库、Git、Slack、Jira、内部 API生态可复用：业界形成的 MCP Server 可以直接拿来用解耦工具与模型：工具实现不绑定特定 LLM，切换模型成本更低MCP 接入最佳实践实践说明永远不要把 MCP Server 直接暴露给 Agent必须经过 Tool Registry。MCP 提供"能力"，Harness 提供"治理"给每个 MCP Server 单独配额一个流氓 MCP Server 不应该拖垮整个系统白名单而非黑名单哪怕 MCP Server 暴露了 50 个工具，也只把业务真正需要的几个开放给特定 Agent高风险工具走 Human-in-the-Loop文件写入、删除、代码执行、数据库写、外部支付不能让 Agent 自动执行所有 MCP 调用都要打 Trace工具来源、参数、结果、调用者必须可追溯MCP 让工具接入变得便宜，Harness 让工具调用变得可信。两者必须搭配，不可偏废。八、可观测性传统后端出问题看日志、指标、链路。Agent 系统更需要这些，因为 Agent 的错误往往不是异常，而是过程偏移。过程偏移的表现：调用了错误工具读取了错误记忆误解了用户目标因为压缩丢了关键约束因为预算不足提前收束因为路由用了能力不够的小模型九、落地路线：分三阶段演进Phase 1 — MVP跑通一条端到端业务闭环：最小 Orchestrator + Tool Registry简单状态 + 基础 Trace评估数据集不要一开始就上动态 Planner、十个 Agent、复杂长期记忆。先把一条链路跑稳。Phase 2 — Hardening把 Demo 变成可控系统：增加 Budget、权限、重试、压缩轨迹评估、审计、回归测试重点解决"为什么错、哪里贵、哪里慢、哪里不安全"Phase 3 — Scale支撑更多场景与并发：分布式队列、多租户隔离动态模型路由、Agent 质量排行榜A/B 测试、长期记忆治理统一 MCP 接入平台、成本看板技术选型建议团队类型推荐方案小团队LangGraph 或自研轻量状态机 + FastAPI + Redis + PostgreSQL/pgvector + Langfuse/OpenTelemetry + LiteLLM 网关企业团队更重视权限、审计、多租户、成本中心、数据治理。MCP 作为接入标准，但不允许直连 Agent研究团队可探索动态 Planner、自反思、自动 Eval、长期记忆压缩，但务必区分研究效果和生产 SLA总结未来的竞争，不是"谁的 Agent 更多"，而是"谁的 Harness 更稳"。落地前必须回答的十个问题任务怎么进来？谁负责拆解？谁负责调度？工具怎么接？状态放哪里？记忆怎么检索？预算怎么控制？轨迹怎么评估？失败怎么处理？审计怎么保留？把这十个问题回答清楚，你就已经越过了大多数 Agent Demo 的边界。组织层面提醒Multi-Agent Harness 不是纯算法项目，而是系统工程。它需要算法、后端、平台、安全、业务专家的多角色协同。如果团队只让一个"会写 Prompt 的同学"负责全部，几乎一定卡在 Demo 阶段。

AI 应用开发Ⅰ 1. Skill 管理与 System Prompt 优化问题：Skill 太多占用上下文窗口方案：Skill 做成外部注册表，system prompt 只保留最小规则和调用协议，按需动态注入Skill Routing：用规则/分类模型/向量检索筛 top-k skillSkill 信息拆成摘要版和完整版，先注入摘要，确认调用后再加载详细说明，显著压缩 token2. Skill 消歧（Description 相似导致误召回）解决思路（四步走）：将 skill 从纯文本 description 升级为结构化定义（适用场景、禁用场景、输入参数、返回格式、前置条件、失败条件、调用示例）两阶段选择：先召回 top-k → 再让模型根据参数约束和样例做 rerank加入负样本示例，明确告诉模型什么问题不应该调用这个 skill执行前做 schema 校验和 rule check，即使模型选错也不能继续误调长期方案：如果两个 skill 语义长期接近，考虑在系统设计层面合并成一个 skill，再由内部参数路由3. Agent 设计核心 — 上下文工程Agent 最终不是单轮问答，而是一个持续决策系统。模型能看到什么信息、这些信息的顺序和优先级、哪些是规则/证据/历史状态，都会直接影响 Agent 的稳定性。核心原则：不是"给模型更多信息"，而是"给模型正确的信息"。4. 上下文工程注意事项要点说明角色隔离system、developer、user、tool output、memory 的优先级和边界要清楚，外部文本和系统规则不能混在一起信息裁剪只保留当前任务相关内容，避免把所有历史对话/检索结果/工具说明一股脑灌进去格式控制结构化上下文比纯自然语言更稳（工具结果用 JSON、任务状态字段化、长历史做摘要）来源可信度分层系统规则 > 用户输入 > 工具结果 > 模型猜测 > 无依据生成上下文压缩与淘汰长任务需做压缩和过期淘汰，避免状态漂移和旧信息污染新决策5. 长期记忆设计（写回、衰减、冲突消解）写回策略只保存高价值稳定信息：用户偏好、身份属性、长期任务目标、反复出现的业务事实做结构化抽取（如 profile 字段），而非原文整段存储衰减策略短期热点信息：高权重，随时间衰减长期稳定偏好：低频刷新，不轻易删除冲突消解结合时间戳、来源可信度、置信度新的高可信事实覆盖旧事实，低可信内容只作为候选高级方案事件流 + 物化视图：所有记忆写入先存成 event，再异步聚合成 profile，方便审计和回滚6. 并行 Tool Calling核心要点：只有互不依赖的工具才能并行（如天气查询和汇率查询可一起发）有依赖关系的必须串行一致性保障：工具执行结果先写到临时观察区，再由调度器统一合并，避免并发写导致状态污染可回放性：每次调用带 trace_id、step_id、输入参数、输出结果和耗时，组成完整执行 DAG失败处理：按工具粒度重试，不能因为一个工具超时就把全部结果丢掉副作用操作：发消息、创建订单等需加幂等键，防止重复重试造成真实业务重复写入7. 主流 Agent 设计模式模式特点适用场景ReAct边推理边行动（思考→调用→观察→继续思考）通用场景Plan-and-Execute先规划再按步骤执行长任务，比纯 ReAct 更稳Router先做任务分类，再路由给不同子 Agent/工具链多能力分发Workflow + Agent固定流程嵌局部自主决策线上业务常用Supervisor主 Agent 拆解任务并分派给多个子 Agent多 Agent 协作Blackboard多 Agent 通过共享状态协作多 Agent 协作点对点自由协作Agent 间自由协作线上较少，不易治理8. MCP vs A2A vs Function Calling协议抽象层级适用场景Function Calling调用一个函数单应用内工具调用，模型输出结构化调用意图，宿主进程负责执行MCP暴露一组标准能力多模型客户端/IDE 共享一套工具和资源能力，统一封装资源、工具、提示模板A2A多智能体协作完成任务多 Agent 分工协作、任务转派和结果汇总本质区别：抽象层级不同 — 函数调用 → 能力暴露 → 智能体协作9. RAG 接入 Agent 的设计RAG 应作为决策节点，而非固定的"先查再答"模型先判断是否需要外部知识 → 决定 query rewrite → query decomposition → 召回 → rerank → 生成常见做法：把 RAG 包成一个工具，Agent 自己决定何时调用检索结果需做去重、切片、排序、来源标注生成时要求模型只根据检索到的证据回答，没有证据就明确说不确定，降低幻觉10. Tool Calling 工程实现四层架构：层级职责工具注册层管理可用工具参数 schema 层定义参数格式和约束执行器层实际执行工具调用审计日志层记录调用链路服务端职责：白名单校验、参数校验、超时控制、幂等控制、错误包装核心原则：模型只能输出候选调用，不能把工具执行权直接交给模型11. Agent Memory 分层层级用途特点短期记忆最近几轮对话 + 当前任务状态保证会话连贯长期记忆稳定事实（用户偏好、身份、目标）持久化存储摘要记忆压缩旧对话为关键事实减少 token 占用落地策略：保留最近 N 轮原文 → 更久远内容压成 summary → 抽取关键字段单独存储 → 按需召回，不全量拼接12. Prompt Injection 防护（Agent 场景）风险：不仅生成错误文本，还可能误调工具、越权执行、触发真实业务操作分层防护：角色和优先级隔离：外部知识不能覆盖系统规则文档视为证据：检索文档视为证据，不视为命令工具调用管控：白名单 + 参数校验，高风险操作显式确认链路可追踪：输出和调用链路必须可追踪，出问题能回放输入清洗：对明显越权或诱导内容做拦截核心思想：靠系统设计让模型即使被诱导，也没有越权能力13. Agent 效果评估（四层）层级评估维度回答质量准确性、完整性、是否基于证据工具质量选工具是否正确、参数是否正确、调用是否成功任务质量一次会话是否完成目标、是否需要额外追问、是否需要人工接管系统质量耗时、成本、token、错误率、稳定性如果有 RAG，还需单独评估：召回命中率、rerank 效果、答案引用质量核心观点：Agent 不是单个模型的分数，而是整条链路的分数14. 线上工具选错排查路径检查 tool description 和 schema 设计，边界是否模糊，参数是否能区分场景检查 skill routing 层，是否一次性喂了过多候选工具造成噪声竞争检查 prompt 和 few-shot 示例是否给了错误引导，或是否最近改过 system prompt回放 trace，检查模型选工具前看到的上下文、历史记忆是否污染当前判断、用户输入是否歧义严重排查原则：不是看最后一步，而是看"候选集是怎么来的、模型为什么这么选、执行前有没有二次校验"15. 长任务防死循环限制手段：最大推理步数最大工具调用次数最大 token 开销最大执行时长条件定义：明确什么叫完成、什么叫失败、什么情况需要让用户补信息重复动作检测：连续多步调用同一工具/得到相似结果/没有带来新证据 → 强制终止并返回阶段性结论总结Agent 系统的关键不在于模型能力有多强，而在于：上下文工程：给模型正确的信息，而非更多信息系统设计：安全边界、校验层、可回放分层架构：记忆分层、评估分层、防护分层