1、什么是 Agent与大模型的区别传统AI大模型是对输入的文本只依赖已拥有的信息输出文字回答。Agent能规划问题解决流程调用外部工具搜索未知信息编写并执行代码纠正问题评审结果输出结果。重点自主性、能动性。比如你能让他帮你清日常2、Agent 的基本架构由哪些核心组件构成LLMlarge language model、工具、记忆、规划模块LLM 是整个系统的大脑负责理解任务和做决策工具让 Agent 能跟外部世界交互搜索、执行代码、调 API 都靠它记忆让 Agent 在任务执行过程中保持状态不会「失忆」规划模块负责把复杂目标拆解成可执行的步骤。3、WorkflowAgentToolsTools 是最小的能力单元就是封装好的可调用函数比如搜索、执行代码、发邮件它只负责「执行」本身没有任何决策能力。Agent 是一个完整的决策系统内部用 LLM 做大脑自己判断什么时候调哪个 Tool、要不要继续、什么时候结束是主动的。Workflow 是更上层的编排框架把 Agent、LLM、Tools 组织成一条确定性流程每个节点做什么、按什么顺序流转都是开发者事先写死的。三者最核心的区别就一句话Tools 不做决策只执行Agent 自己做决策Workflow 是开发者替所有节点把决策提前写好。4、Agent 设计范式ReAct、Plan-and-Execute、ReflectionReAct Thought - Action - Observation 循环「走一步看一步」每一步都是局部最优决策。Plan-and-Execute规划和执行解耦先做规划输出一个完整的步骤列表然后逐步执行每执行完一步都会把结果反馈给规划器规划器会判断是否需要更新计划。既保持了全局视野又不会因为死板而失效。Reflection「质量保障」。在 Agent 完成一步或者完成整个任务之后再判断做得好不好、结果是否符合预期。如果评估不通过就重试或者换一种策略。这个机制能显著提升输出质量。变体——Reflexion。不只是说「这个结果不好重做一遍」而是会生成一段具体的「反思总结」记录下这次失败的原因和改进建议然后把这段总结作为额外的上下文传给下一次尝试。5、Agent 推理模式CoT、ToT、GoT1CoT全称 Chain of Thought两种触发方式。Zero-shot CoT直接在 prompt 末尾加上「让我们一步步思考」这句话就行了零成本、即插即用缺点是发挥不稳定。Few-shot CoT需要在 prompt 里给几个带有完整推理过程的例子让 LLM 照着这个格式来模仿。LLM 会按照同样的格式展开推理。Few-shot 的效果更稳定特别适合输出格式要求比较固定的场景代价是需要你提前准备高质量的示例而且示例本身也会占用 token。2ToT 全称是 Tree of Thoughts思维树针对的正是 CoT「一旦走错就全错」的问题。核心改变是把「生成一条推理链」变成「同时探索多条推理路径边探索边剪枝最终选出最优路径」。3GoT 全称是 Graph of Thoughts思维图是在 ToT 基础上再进一步的进化。解决了「不同推理路径的中间结论能不能复用」的问题答案是把结构从树换成图自然支持结论汇聚与复用。每一步都是在前一步的基础上发现局限、针对性改进。6、复杂任务拆分为什么怎么拆分拆分结果的验证标准拆完还要做的事为什么拆分LLM 的 context window 有上限任务越大中间状态越多、越容易出错而且拆开后每步可以独立验证和重试。怎么拆分静态、动态、自适应1静态拆分适合流程固定的场景提前把步骤写死2动态拆分让 LLM 自己根据目标规划步骤更灵活但也更难控制。 Plan-and-Execute 3自适应拆分做不好就继续拆。不在开始时就把所有步骤的粒度定死先让执行器尝试完成当前任务如果做得好就继续往下走不做多余的拆分否则把这个「做不好的任务」交给规划器让规划器把它进一步拆成更小的子任务然后对每个子任务重复同样的流程。拆分结果的验证标准完备、独立、可验证1「完备性」所有步骤加在一起能不能覆盖原始任务的全部要求有没有遗漏。2「独立性」也就是每个步骤的职责边界是不是清晰有没有两个步骤在做同一件事或者某个步骤的输出和另一个步骤的输出有重叠。3「可验证性」也就是每个步骤执行完之后能不能用一个简单的标准判断它做对了没有。这一点在实际项目中特别容易被忽视但它直接决定了你能不能做自动重试和质量把控。拆完还要做的事分析步骤依赖关系把能并行的步骤并发跑节省关键路径时间。7、Agent 的记忆机制如何设计1分类感知记忆当前输入的原始内容、短期记忆context window 里的对话历史存当前任务的中间状态任务结束就清掉、长期记忆存在外部数据库、语义检索召回、实体记忆结构化提取的关键事实。3三个工程核心问题存什么只存对下次任务有价值的内容、怎么存语义内容用embding向量数据库靠语义相似度检索结构化偏好用关系数据库混合存储是主流、什么时候取任务开始前主动检索加载背景执行中按需检索特定知识。8、记忆存的粒度是多少通常按「一次完整交互」或「一个关键事件」为单位存太细碎检索噪音大太粗糙又丢失细节。9、什么是 Multi-Agent为什么要用多个Agent多智能体系统Multi-Agent就是多个 Agent 协作完成任务每个 Agent 各有分工。单个 Agent 主要受两个限制1一是context 窗口大小复杂任务信息量一多就撑爆了2二是单点能力什么都让一个 Agent 做每件事都是泛才。Multi-Agent 通过专业分工和并行执行能处理更复杂、更长流程的任务。10、Single-Agent 和 Multi-Agent 的适用场景设计方案Single-Agent适合任务流程清晰、复杂度适中的场景实现简单、好维护Multi-Agent适合需要专业分工、任务量大或者需要并行执行的复杂场景。Multi-Agent 架构上主要有两种拓扑中心化的 Orchestrator 模式由一个主 Agent 统一调度各个 Worker去中心化的 Peer-to-Peer 模式Agent 之间直接通信。在工程里用中心化用得更多因为好控制、好调试出问题链路清晰。11、Agent 记忆压缩方法1信息层滑动窗口、摘要压缩、重要性过滤、结构化抽取。时间维度滑动窗口和摘要压缩解决「历史太长怎么截」前者直接硬截后者截之前先提炼内容维度重要性过滤解决「内容不等价怎么挑」打破时间顺序按价值保留结构化抽取解决「对话文本是不是最佳载体」换一种信息密度更高的形式存储。2Prompt Caching上面这些「信息层」的压缩策略还有一个「计算层」技术叫 Prompt Caching。背景LLM 每次处理请求都需要把输入的所有 token「过一遍模型」来做计算这个过程叫 prefill是延迟和成本的主要来源之一。常见的场景一段固定的 system prompt 加上越来越长的对话历史每次调用时这段历史都会被重新计算一遍哪怕它和上一次调用时完全一样。Prompt Caching 的思路如果 prompt 的前缀部分在多次请求之间是一样的就把这部分的计算结果缓存起来下次请求如果前缀匹配直接复用缓存不重新计算。费用和延迟都大幅降低某些场景下能降到原来的十分之一。记忆压缩和Prompt Caching 可以同时使用是互补关系不是替代。12、「手搓」Agent和成熟框架1框架用起来快但有几个实际痛点。第一是抽象层太多调试的时候不知道哪步出了问题得一层层往下扒第二是版本升级经常有破坏性变更线上稳定性难保证第三是框架的通用设计往往和具体业务需求有偏差定制起来反而更费劲。2手搓代码完全在自己掌控之内可观测性好、出问题好排查也更方便做性能优化。所以策略是核心逻辑手写只在边缘功能上用框架的工具。13、如何赋予 LLM 规划能力1CoT 是让 LLM 把推理步骤写出来线性地一步步推导到答案2ToT 是让它同时探索多条推理路径选最优的继续深入3GoT 是图结构推理推理节点可以复用和合并适合更复杂的任务。用 CoT 最多因为实现成本最低就是改个 promptToT 效果更好但调用次数多成本大概是 3 到 5 倍GoT 目前还比较学术没有真正落地用的。14、Agent 的反思机制Reflection为什么要用具体怎么实现粒度分级为什么 LLM 第一次输出不一定是最优的加一轮自我检查能显著提升质量。具体实现核心循环生成 - 评估 - 改进生成1评估 ①需要明确的检查维度事实、逻辑、完整性、表达而不是让 LLM 自由发挥。这很重要没有方向的评估往往流于表面LLM 可能只是说「输出看起来不错」没有真正找到问题。给出具体维度它才会有针对性地逐项审查。②「PASS」机制给 LLM 一个「足够好就停」的出口。如果没有这个机制LLM 为了反思而反思可能对一个已经很好的输出挑不必要的小毛病反而把原本对的东西改错。2改进需要同时传入“原始任务、原始输出、评估意见”这三样东西缺任何一个都会让改进变得盲目。粒度分级步骤级和任务级步骤级反思能在第一步就发现关键词的问题马上纠正后续步骤都建立在正确基础上。适合步骤之间强依赖、前一步错了后面会全错的任务。代价是延迟和 token 消耗会大幅增加。任务级反思是整个任务执行完之后做一次整体评估。好处是开销更小整个任务只多一次 LLM 调用而且从整体视角审视能发现步骤级看不到的问题各个步骤单独看都是对的但整体结论前后矛盾或者各部分之间衔接不自然这种问题只有从整体视角才能看出来。代价是如果任务中途某步出了大问题到最后才发现前面的执行都已经浪费了。适合步骤之间相对独立、最终输出的整体质量更重要的场景比如生成一份报告。15、多 Agent 的协作与动态切换机制1协作方式消息传递和共享状态①消息传递解耦 Agent 完成自己的工作后把结果发出去下一个 Agent 取用②共享状态所有 Agent 共同读写一个状态对象记录任务进展和中间结果。要点状态结构要分层「全局状态」和「局部状态」两层。全局状态存放所有 Agent 都需要读取的信息。局部状态存放每个 Agent 自己的中间结果不会直接暴露给其他 Agent避免信息污染。写入规则要明确。「只追加不覆盖」每个 Agent 完成工作后把结果追加到状态里而不是修改已有的字段。错误状态的处理。如果某个 Agent 执行失败了它的错误信息也应该写入状态。后续的 Agent 或者 Orchestrator 读到这个错误状态后才能做出正确的决策比如跳过这一步、换一个 Agent 重试、或者直接终止任务。2动态切换静态路由、动态决策靠 Orchestrator 做两种方式静态路由提前写好规则「任务类型 A 就找 Agent X」动态决策让 LLM 根据当前情况实时判断该把任务交给谁。16、Agent 的上下文工程设计Context Engineering设计成一个运行时装配流程。每次模型调用前指令决定行为边界任务状态决定执行位置Memory 补充过去RAG 和工具结果补充外部事实。它们都进入上下文但职责并不相同。1上下文结构指令、任务状态、对话与 Memory、外部观察①指令System 指令规定 Agent 的“身份”和“底线”Developer 指令放“工作流程”和“输出格式”User 指令表达用户这一次明确要完成的事。高优先级规则不能被低优先级内容覆盖。②任务状态目标是什么核心目标、成功标准、硬约束底线做到哪一步了当前步骤、已完成项、关键产物引用已生成的东西放哪了还有啥没做待办项、待确认问题。③对话与 Memory。最近几轮对话保留当前语境长期 Memory 提供跨会话的稳定信息比如用户偏好、已确认配置和历史决策。但 Memory 只是候选背景不是永远正确的事实。用户刚刚修改了技术栈旧 Memory 里原来的技术栈就应该失效不能因为存得更久反而拥有更高优先级。④外部观察包括工具定义、工具执行结果和 RAG 检索证据。工具定义告诉模型当前能做哪些动作工具结果告诉模型动作产生了什么RAG 证据则提供回答或决策所需的外部知识。这些内容通常很长而且质量参差不齐更需要按当前步骤动态选择。2上下文装配挑选内容、内容排序优先级、隔离、Token 预算分配、闭环①挑选内容首先判断当前模型调用到底要完成哪个子任务。根据四个维度筛选所需内容与当前步骤的相关性、来源可信度、信息新鲜度、缺失后的风险。②内容排序优先级让稳定、权威的行为规则在前面随后放用户当前目标和结构化任务状态再放本轮需要的工具说明、RAG 证据与工具观察最后明确要求模型输出什么。具体顺序可以根据模型和任务通过评测调整但「规则、状态、数据」一定要分区隔离不能混成一段没有边界的长文本避免混淆模型判断。③隔离工程上要把指令区和数据区明确分开对 RAG 文档、网页、邮件、代码注释和工具返回值加上来源、时间、权限、内容类型等元数据并告诉模型只能把它们当作待分析数据。权限校验必须由模型之外的程序执行不能只靠一句 Prompt 约束。隔离也适用于工具和子 Agent。当前步骤只暴露必要工具高风险工具在外部增加参数校验、权限检查和人工确认子 Agent 只拿自己的子任务、局部状态和必要证据不要默认继承主 Agent 的全部历史。这样既减少 Token也降低无关信息和恶意内容跨步骤扩散的概率。④Token 预算分配模型需要空间输出答案、生成工具参数或写代码。所以预算的第一步是根据任务预留输出 Token 和安全余量剩下的容量才分给输入。如果仍然超长按「去重 - 移除低相关工具和证据 - 结构化状态替代冗长过程 - 压缩较旧历史」的顺序降载。用户硬约束、当前目标、安全规则和未完成状态属于不可随意丢失项。实在装不下时宁可分步检索或向用户确认也不要静默截掉关键要求。记忆压缩研究的是长历史如何缩短上下文工程关心的是整个工作台怎么装配。压缩只是预算不够时的一种手段不能替代对工具、证据、状态和指令的选择。⑤每一步都运行的闭环Agent 调完工具之后当前事实和下一步目标已经变化了。如果继续沿用上一轮完整 Prompt只在末尾追加一段工具结果上下文会越来越臃肿旧计划也可能持续干扰新决策。因此需要重新进行上下文装配。16、Context Engineering 和 Prompt Engineering 有什么区别Prompt Engineering主要在设计「怎么说」比如角色怎么描述、任务怎么拆、输出格式怎么约束、Few-shot 示例怎么写。它关注的是指令和模板本身是否清晰、稳定。Context Engineering关注的是「这一轮让模型看到什么」。除了 Prompt还包括从哪里取任务状态、召回哪段 Memory、开放哪些工具、放哪些 RAG 证据、如何处理工具结果以及这些内容怎么排序、隔离和控制预算。它贯穿 Agent 的整个运行过程是动态的。Memory 则更像仓库负责跨时间保存和召回信息上下文是工作台只摆本轮需要的内容。记忆压缩是在仓库或工作台太拥挤时降低内容体积的一类方法。RAG 是给工作台找资料的机制也不等于上下文工程本身。一句话区分就是Prompt Engineering 把话写清楚Memory 把信息存下来RAG 把证据找回来Context Engineering 决定这一次到底把哪些东西摆到模型面前。17、Agent 的多轮对话状态管理多轮对话一长段自然语言用户的输入、AI的思考过程及输出为什么要管理当发生“中断”时需要让系统快速恢复到中断前的状态继续执行而不是从一长串聊天记录多轮对话中猜/重新整理得到信息。多轮对话状态管理定义通过结构化的方式持续记录和维护任务的目标、约束、进度和中间产物确保 Agent 在每一轮对话中都能准确续接上下文而不是每次都从零开始猜测用户意图。如何实现“Agent 的多轮对话状态管理”信息分类、保存载体、状态更新1信息分类①对话历史保留用户和模型说过的原话②业务状态保存已经确认的实体与约束用户明确的“人、事、物、条件”当成后续所有步骤的“既定事实”不再重复确认、不再重新猜测。③任务状态记录目标、当前步骤和工具执行进度④长期记忆只保存跨任务仍然有价值的用户偏好与历史经验。2保存载体①简单场景用 JSON 对象保存状态字段。②复杂场景用状态机或 LangGraph 的 State每个节点读写自己关心的字段。状态字段多轮对话里的“记忆格子”——每个格子记一类关键信息让AI不用翻聊天记录也能知道任务进行到哪了。状态字段的划分「为什么做、做到哪、还差什么」目标、进度、待办、既定事实、产物3状态更新每一轮对话结束后明确哪些字段新增如新确认了一个约束哪些字段修改如当前步骤从“等确认”变成“生成SQL”哪些字段归档如已完成的待办项移入“已完成”***注如果用户的输入与“目标”相似度低需要判断是在进行“切换任务”/“补充信息”或者跑偏了18、如何防止跑偏Agent 跑偏通常不是突然忘掉整项任务而是在多次小偏差中慢慢发生误差累计。工具返回了一段无关内容模型顺着展开用户插入一个临时问题Agent 回答完却忘了主线摘要反复压缩以后验收条件被压没了。这些都不是单纯增加历史长度能解决的。1始终保留结构化的“目标”。它不只是一句任务标题还应该包含最终产物、必须满足的约束和完成标准。每次规划或检查前把它和“进度”一起提供给模型让模型知道当前步骤为什么存在。2进度核对。每完成一个关键步骤Checker 都要问两个问题这个结果是否推进了核心目标下一步是否仍来自未完成计划。若连续步骤与目标弱相关、重复修改同一状态或者新计划无故丢掉验收条件就进入重新规划或人工澄清而不是继续消耗 Token。3保留事实来源和状态版本。工具结果出错时不应该让后面的摘要把错误结论包装成确定事实。“既定事实”里的关键字段可以带上来源、置信度和更新时间用户纠正后让依赖旧值的步骤失效再从受影响的位置重新规划。19、如何实现中断恢复定位、对齐、续接先看“任务状态”这张卡片找到 current_step 和 todos从断点接着走而不是从头再来。20、如何评估一个 Agent 的效果评测集和指标怎么设计为什么要评估Agent的最终回复只能回答「它说得怎么样」不能独自证明「事情有没有做成」和「过程是否合规」。最可信的任务成功信号通常是可验证的外部结果。如何评估沿着执行链拆成「工具 - 单步与轨迹 - 端到端任务 - 线上业务」四层。1工具是否可靠①工具先做到可验证校验输入Schema/必填/类型/范围覆盖正常、空、超时、权限失败、第三方异常有副作用则测幂等。②模型的工具决策一是工具选择是否正确二是参数是否正确。2单步决策和完整轨迹是否合理①单步评测在某个固定状态下问Agent 下一步该做什么适合快速验证工具选择、参数生成、是否应该向用户追问信息以及是否应该结束任务。②轨迹评测把整条工具调用序列拿出来看。根据任务定义三类约束哪些步骤必须出现哪些步骤禁止出现哪些步骤有先后依赖。剩下的路径允许 Agent 自己选择。不必迷信「理论最短路径」因为多一步验证可能换来更高安全性。效率应该在成功且合规的前提下比较。3端到端任务是否真的完成端到端评测把 Agent 当成一个整体核心指标是任务完成率也就是满足成功条件的任务数占全部评测任务的比例。关键「成功条件的定义」、对同一任务能否重复运行4线上业务是否得到改善用户和业务真的受益吗业务效果、延迟、Token、成本和安全。评测集与指标的设计1样本来源真实请求、边界场景、对抗与安全样本、历史 Badcase。①真实请求。对生产日志去除隐私信息后按任务类型、难度、工具、对话轮数和风险等级分层采样不能只抽最常见、最容易的请求。②边界场景。比如参数缺失、时间表达含糊、工具超时、返回空结果、上下文很长、多个工具都像能用。这些题不一定高频却最容易暴露工程问题。③对抗与安全样本。比如工具返回中藏着提示词注入用户要求越权读取数据或者诱导 Agent 绕过确认流程。它们用来检验安全边界而不是追求平均体验分。④历史 Badcase。线上每出现一种新的失败模式人工确认原因后就把有代表性的样本加入回归集。这样评测集不是一次性作业而是在记录系统真实踩过的坑。2指标评分设计确定性检查、人工评审和 LLM-as-a-Judge 三者组合使用。①确定性检查应该优先使用。 参数能否通过 Schema、是否调用禁用工具、数据库最终状态是否正确、代码是否通过测试这些都可以由程序直接判断。它速度快、成本低、结果稳定也最适合放进持续集成。②人工评审负责定义标准和处理高风险歧义。 领域专家适合判断政策是否遵循、开放式结果是否有用也适合审查自动裁判分歧大的样本。人工不一定要评全部数据更重要的是建立清楚的 Rubric并持续抽查自动评测是否跑偏。Rubric 评分标准表③LLM-as-a-Judge 负责扩展开放式评测。 例如报告是否完整、回复有没有解决问题、整条轨迹是否合理很难用字符串匹配判断这时可以让大模型按 Rubric 输出结构化分数和理由。3产品发布“门禁”很多团队最后会做一个综合分但综合分不能解决所有决策。更合理的做法是先设硬门禁再看质量与效率。安全违规、越权动作、绕过必要审批、重复产生严重副作用这些样本只要失败就应该阻止发布。对于普通质量指标再根据业务目标比较任务完成率、轨迹质量、延迟和成本。 记录-Agent学习
1、什么是 Agent与大模型的区别传统AI大模型是对输入的文本只依赖已拥有的信息输出文字回答。Agent能规划问题解决流程调用外部工具搜索未知信息编写并执行代码纠正问题评审结果输出结果。重点自主性、能动性。比如你能让他帮你清日常2、Agent 的基本架构由哪些核心组件构成LLMlarge language model、工具、记忆、规划模块LLM 是整个系统的大脑负责理解任务和做决策工具让 Agent 能跟外部世界交互搜索、执行代码、调 API 都靠它记忆让 Agent 在任务执行过程中保持状态不会「失忆」规划模块负责把复杂目标拆解成可执行的步骤。3、WorkflowAgentToolsTools 是最小的能力单元就是封装好的可调用函数比如搜索、执行代码、发邮件它只负责「执行」本身没有任何决策能力。Agent 是一个完整的决策系统内部用 LLM 做大脑自己判断什么时候调哪个 Tool、要不要继续、什么时候结束是主动的。Workflow 是更上层的编排框架把 Agent、LLM、Tools 组织成一条确定性流程每个节点做什么、按什么顺序流转都是开发者事先写死的。三者最核心的区别就一句话Tools 不做决策只执行Agent 自己做决策Workflow 是开发者替所有节点把决策提前写好。4、Agent 设计范式ReAct、Plan-and-Execute、ReflectionReAct Thought - Action - Observation 循环「走一步看一步」每一步都是局部最优决策。Plan-and-Execute规划和执行解耦先做规划输出一个完整的步骤列表然后逐步执行每执行完一步都会把结果反馈给规划器规划器会判断是否需要更新计划。既保持了全局视野又不会因为死板而失效。Reflection「质量保障」。在 Agent 完成一步或者完成整个任务之后再判断做得好不好、结果是否符合预期。如果评估不通过就重试或者换一种策略。这个机制能显著提升输出质量。变体——Reflexion。不只是说「这个结果不好重做一遍」而是会生成一段具体的「反思总结」记录下这次失败的原因和改进建议然后把这段总结作为额外的上下文传给下一次尝试。5、Agent 推理模式CoT、ToT、GoT1CoT全称 Chain of Thought两种触发方式。Zero-shot CoT直接在 prompt 末尾加上「让我们一步步思考」这句话就行了零成本、即插即用缺点是发挥不稳定。Few-shot CoT需要在 prompt 里给几个带有完整推理过程的例子让 LLM 照着这个格式来模仿。LLM 会按照同样的格式展开推理。Few-shot 的效果更稳定特别适合输出格式要求比较固定的场景代价是需要你提前准备高质量的示例而且示例本身也会占用 token。2ToT 全称是 Tree of Thoughts思维树针对的正是 CoT「一旦走错就全错」的问题。核心改变是把「生成一条推理链」变成「同时探索多条推理路径边探索边剪枝最终选出最优路径」。3GoT 全称是 Graph of Thoughts思维图是在 ToT 基础上再进一步的进化。解决了「不同推理路径的中间结论能不能复用」的问题答案是把结构从树换成图自然支持结论汇聚与复用。每一步都是在前一步的基础上发现局限、针对性改进。6、复杂任务拆分为什么怎么拆分拆分结果的验证标准拆完还要做的事为什么拆分LLM 的 context window 有上限任务越大中间状态越多、越容易出错而且拆开后每步可以独立验证和重试。怎么拆分静态、动态、自适应1静态拆分适合流程固定的场景提前把步骤写死2动态拆分让 LLM 自己根据目标规划步骤更灵活但也更难控制。 Plan-and-Execute 3自适应拆分做不好就继续拆。不在开始时就把所有步骤的粒度定死先让执行器尝试完成当前任务如果做得好就继续往下走不做多余的拆分否则把这个「做不好的任务」交给规划器让规划器把它进一步拆成更小的子任务然后对每个子任务重复同样的流程。拆分结果的验证标准完备、独立、可验证1「完备性」所有步骤加在一起能不能覆盖原始任务的全部要求有没有遗漏。2「独立性」也就是每个步骤的职责边界是不是清晰有没有两个步骤在做同一件事或者某个步骤的输出和另一个步骤的输出有重叠。3「可验证性」也就是每个步骤执行完之后能不能用一个简单的标准判断它做对了没有。这一点在实际项目中特别容易被忽视但它直接决定了你能不能做自动重试和质量把控。拆完还要做的事分析步骤依赖关系把能并行的步骤并发跑节省关键路径时间。7、Agent 的记忆机制如何设计1分类感知记忆当前输入的原始内容、短期记忆context window 里的对话历史存当前任务的中间状态任务结束就清掉、长期记忆存在外部数据库、语义检索召回、实体记忆结构化提取的关键事实。3三个工程核心问题存什么只存对下次任务有价值的内容、怎么存语义内容用embding向量数据库靠语义相似度检索结构化偏好用关系数据库混合存储是主流、什么时候取任务开始前主动检索加载背景执行中按需检索特定知识。8、记忆存的粒度是多少通常按「一次完整交互」或「一个关键事件」为单位存太细碎检索噪音大太粗糙又丢失细节。9、什么是 Multi-Agent为什么要用多个Agent多智能体系统Multi-Agent就是多个 Agent 协作完成任务每个 Agent 各有分工。单个 Agent 主要受两个限制1一是context 窗口大小复杂任务信息量一多就撑爆了2二是单点能力什么都让一个 Agent 做每件事都是泛才。Multi-Agent 通过专业分工和并行执行能处理更复杂、更长流程的任务。10、Single-Agent 和 Multi-Agent 的适用场景设计方案Single-Agent适合任务流程清晰、复杂度适中的场景实现简单、好维护Multi-Agent适合需要专业分工、任务量大或者需要并行执行的复杂场景。Multi-Agent 架构上主要有两种拓扑中心化的 Orchestrator 模式由一个主 Agent 统一调度各个 Worker去中心化的 Peer-to-Peer 模式Agent 之间直接通信。在工程里用中心化用得更多因为好控制、好调试出问题链路清晰。11、Agent 记忆压缩方法1信息层滑动窗口、摘要压缩、重要性过滤、结构化抽取。时间维度滑动窗口和摘要压缩解决「历史太长怎么截」前者直接硬截后者截之前先提炼内容维度重要性过滤解决「内容不等价怎么挑」打破时间顺序按价值保留结构化抽取解决「对话文本是不是最佳载体」换一种信息密度更高的形式存储。2Prompt Caching上面这些「信息层」的压缩策略还有一个「计算层」技术叫 Prompt Caching。背景LLM 每次处理请求都需要把输入的所有 token「过一遍模型」来做计算这个过程叫 prefill是延迟和成本的主要来源之一。常见的场景一段固定的 system prompt 加上越来越长的对话历史每次调用时这段历史都会被重新计算一遍哪怕它和上一次调用时完全一样。Prompt Caching 的思路如果 prompt 的前缀部分在多次请求之间是一样的就把这部分的计算结果缓存起来下次请求如果前缀匹配直接复用缓存不重新计算。费用和延迟都大幅降低某些场景下能降到原来的十分之一。记忆压缩和Prompt Caching 可以同时使用是互补关系不是替代。12、「手搓」Agent和成熟框架1框架用起来快但有几个实际痛点。第一是抽象层太多调试的时候不知道哪步出了问题得一层层往下扒第二是版本升级经常有破坏性变更线上稳定性难保证第三是框架的通用设计往往和具体业务需求有偏差定制起来反而更费劲。2手搓代码完全在自己掌控之内可观测性好、出问题好排查也更方便做性能优化。所以策略是核心逻辑手写只在边缘功能上用框架的工具。13、如何赋予 LLM 规划能力1CoT 是让 LLM 把推理步骤写出来线性地一步步推导到答案2ToT 是让它同时探索多条推理路径选最优的继续深入3GoT 是图结构推理推理节点可以复用和合并适合更复杂的任务。用 CoT 最多因为实现成本最低就是改个 promptToT 效果更好但调用次数多成本大概是 3 到 5 倍GoT 目前还比较学术没有真正落地用的。14、Agent 的反思机制Reflection为什么要用具体怎么实现粒度分级为什么 LLM 第一次输出不一定是最优的加一轮自我检查能显著提升质量。具体实现核心循环生成 - 评估 - 改进生成1评估 ①需要明确的检查维度事实、逻辑、完整性、表达而不是让 LLM 自由发挥。这很重要没有方向的评估往往流于表面LLM 可能只是说「输出看起来不错」没有真正找到问题。给出具体维度它才会有针对性地逐项审查。②「PASS」机制给 LLM 一个「足够好就停」的出口。如果没有这个机制LLM 为了反思而反思可能对一个已经很好的输出挑不必要的小毛病反而把原本对的东西改错。2改进需要同时传入“原始任务、原始输出、评估意见”这三样东西缺任何一个都会让改进变得盲目。粒度分级步骤级和任务级步骤级反思能在第一步就发现关键词的问题马上纠正后续步骤都建立在正确基础上。适合步骤之间强依赖、前一步错了后面会全错的任务。代价是延迟和 token 消耗会大幅增加。任务级反思是整个任务执行完之后做一次整体评估。好处是开销更小整个任务只多一次 LLM 调用而且从整体视角审视能发现步骤级看不到的问题各个步骤单独看都是对的但整体结论前后矛盾或者各部分之间衔接不自然这种问题只有从整体视角才能看出来。代价是如果任务中途某步出了大问题到最后才发现前面的执行都已经浪费了。适合步骤之间相对独立、最终输出的整体质量更重要的场景比如生成一份报告。15、多 Agent 的协作与动态切换机制1协作方式消息传递和共享状态①消息传递解耦 Agent 完成自己的工作后把结果发出去下一个 Agent 取用②共享状态所有 Agent 共同读写一个状态对象记录任务进展和中间结果。要点状态结构要分层「全局状态」和「局部状态」两层。全局状态存放所有 Agent 都需要读取的信息。局部状态存放每个 Agent 自己的中间结果不会直接暴露给其他 Agent避免信息污染。写入规则要明确。「只追加不覆盖」每个 Agent 完成工作后把结果追加到状态里而不是修改已有的字段。错误状态的处理。如果某个 Agent 执行失败了它的错误信息也应该写入状态。后续的 Agent 或者 Orchestrator 读到这个错误状态后才能做出正确的决策比如跳过这一步、换一个 Agent 重试、或者直接终止任务。2动态切换静态路由、动态决策靠 Orchestrator 做两种方式静态路由提前写好规则「任务类型 A 就找 Agent X」动态决策让 LLM 根据当前情况实时判断该把任务交给谁。16、Agent 的上下文工程设计Context Engineering设计成一个运行时装配流程。每次模型调用前指令决定行为边界任务状态决定执行位置Memory 补充过去RAG 和工具结果补充外部事实。它们都进入上下文但职责并不相同。1上下文结构指令、任务状态、对话与 Memory、外部观察①指令System 指令规定 Agent 的“身份”和“底线”Developer 指令放“工作流程”和“输出格式”User 指令表达用户这一次明确要完成的事。高优先级规则不能被低优先级内容覆盖。②任务状态目标是什么核心目标、成功标准、硬约束底线做到哪一步了当前步骤、已完成项、关键产物引用已生成的东西放哪了还有啥没做待办项、待确认问题。③对话与 Memory。最近几轮对话保留当前语境长期 Memory 提供跨会话的稳定信息比如用户偏好、已确认配置和历史决策。但 Memory 只是候选背景不是永远正确的事实。用户刚刚修改了技术栈旧 Memory 里原来的技术栈就应该失效不能因为存得更久反而拥有更高优先级。④外部观察包括工具定义、工具执行结果和 RAG 检索证据。工具定义告诉模型当前能做哪些动作工具结果告诉模型动作产生了什么RAG 证据则提供回答或决策所需的外部知识。这些内容通常很长而且质量参差不齐更需要按当前步骤动态选择。2上下文装配挑选内容、内容排序优先级、隔离、Token 预算分配、闭环①挑选内容首先判断当前模型调用到底要完成哪个子任务。根据四个维度筛选所需内容与当前步骤的相关性、来源可信度、信息新鲜度、缺失后的风险。②内容排序优先级让稳定、权威的行为规则在前面随后放用户当前目标和结构化任务状态再放本轮需要的工具说明、RAG 证据与工具观察最后明确要求模型输出什么。具体顺序可以根据模型和任务通过评测调整但「规则、状态、数据」一定要分区隔离不能混成一段没有边界的长文本避免混淆模型判断。③隔离工程上要把指令区和数据区明确分开对 RAG 文档、网页、邮件、代码注释和工具返回值加上来源、时间、权限、内容类型等元数据并告诉模型只能把它们当作待分析数据。权限校验必须由模型之外的程序执行不能只靠一句 Prompt 约束。隔离也适用于工具和子 Agent。当前步骤只暴露必要工具高风险工具在外部增加参数校验、权限检查和人工确认子 Agent 只拿自己的子任务、局部状态和必要证据不要默认继承主 Agent 的全部历史。这样既减少 Token也降低无关信息和恶意内容跨步骤扩散的概率。④Token 预算分配模型需要空间输出答案、生成工具参数或写代码。所以预算的第一步是根据任务预留输出 Token 和安全余量剩下的容量才分给输入。如果仍然超长按「去重 - 移除低相关工具和证据 - 结构化状态替代冗长过程 - 压缩较旧历史」的顺序降载。用户硬约束、当前目标、安全规则和未完成状态属于不可随意丢失项。实在装不下时宁可分步检索或向用户确认也不要静默截掉关键要求。记忆压缩研究的是长历史如何缩短上下文工程关心的是整个工作台怎么装配。压缩只是预算不够时的一种手段不能替代对工具、证据、状态和指令的选择。⑤每一步都运行的闭环Agent 调完工具之后当前事实和下一步目标已经变化了。如果继续沿用上一轮完整 Prompt只在末尾追加一段工具结果上下文会越来越臃肿旧计划也可能持续干扰新决策。因此需要重新进行上下文装配。16、Context Engineering 和 Prompt Engineering 有什么区别Prompt Engineering主要在设计「怎么说」比如角色怎么描述、任务怎么拆、输出格式怎么约束、Few-shot 示例怎么写。它关注的是指令和模板本身是否清晰、稳定。Context Engineering关注的是「这一轮让模型看到什么」。除了 Prompt还包括从哪里取任务状态、召回哪段 Memory、开放哪些工具、放哪些 RAG 证据、如何处理工具结果以及这些内容怎么排序、隔离和控制预算。它贯穿 Agent 的整个运行过程是动态的。Memory 则更像仓库负责跨时间保存和召回信息上下文是工作台只摆本轮需要的内容。记忆压缩是在仓库或工作台太拥挤时降低内容体积的一类方法。RAG 是给工作台找资料的机制也不等于上下文工程本身。一句话区分就是Prompt Engineering 把话写清楚Memory 把信息存下来RAG 把证据找回来Context Engineering 决定这一次到底把哪些东西摆到模型面前。17、Agent 的多轮对话状态管理多轮对话一长段自然语言用户的输入、AI的思考过程及输出为什么要管理当发生“中断”时需要让系统快速恢复到中断前的状态继续执行而不是从一长串聊天记录多轮对话中猜/重新整理得到信息。多轮对话状态管理定义通过结构化的方式持续记录和维护任务的目标、约束、进度和中间产物确保 Agent 在每一轮对话中都能准确续接上下文而不是每次都从零开始猜测用户意图。如何实现“Agent 的多轮对话状态管理”信息分类、保存载体、状态更新1信息分类①对话历史保留用户和模型说过的原话②业务状态保存已经确认的实体与约束用户明确的“人、事、物、条件”当成后续所有步骤的“既定事实”不再重复确认、不再重新猜测。③任务状态记录目标、当前步骤和工具执行进度④长期记忆只保存跨任务仍然有价值的用户偏好与历史经验。2保存载体①简单场景用 JSON 对象保存状态字段。②复杂场景用状态机或 LangGraph 的 State每个节点读写自己关心的字段。状态字段多轮对话里的“记忆格子”——每个格子记一类关键信息让AI不用翻聊天记录也能知道任务进行到哪了。状态字段的划分「为什么做、做到哪、还差什么」目标、进度、待办、既定事实、产物3状态更新每一轮对话结束后明确哪些字段新增如新确认了一个约束哪些字段修改如当前步骤从“等确认”变成“生成SQL”哪些字段归档如已完成的待办项移入“已完成”***注如果用户的输入与“目标”相似度低需要判断是在进行“切换任务”/“补充信息”或者跑偏了18、如何防止跑偏Agent 跑偏通常不是突然忘掉整项任务而是在多次小偏差中慢慢发生误差累计。工具返回了一段无关内容模型顺着展开用户插入一个临时问题Agent 回答完却忘了主线摘要反复压缩以后验收条件被压没了。这些都不是单纯增加历史长度能解决的。1始终保留结构化的“目标”。它不只是一句任务标题还应该包含最终产物、必须满足的约束和完成标准。每次规划或检查前把它和“进度”一起提供给模型让模型知道当前步骤为什么存在。2进度核对。每完成一个关键步骤Checker 都要问两个问题这个结果是否推进了核心目标下一步是否仍来自未完成计划。若连续步骤与目标弱相关、重复修改同一状态或者新计划无故丢掉验收条件就进入重新规划或人工澄清而不是继续消耗 Token。3保留事实来源和状态版本。工具结果出错时不应该让后面的摘要把错误结论包装成确定事实。“既定事实”里的关键字段可以带上来源、置信度和更新时间用户纠正后让依赖旧值的步骤失效再从受影响的位置重新规划。19、如何实现中断恢复定位、对齐、续接先看“任务状态”这张卡片找到 current_step 和 todos从断点接着走而不是从头再来。20、如何评估一个 Agent 的效果评测集和指标怎么设计为什么要评估Agent的最终回复只能回答「它说得怎么样」不能独自证明「事情有没有做成」和「过程是否合规」。最可信的任务成功信号通常是可验证的外部结果。如何评估沿着执行链拆成「工具 - 单步与轨迹 - 端到端任务 - 线上业务」四层。1工具是否可靠①工具先做到可验证校验输入Schema/必填/类型/范围覆盖正常、空、超时、权限失败、第三方异常有副作用则测幂等。②模型的工具决策一是工具选择是否正确二是参数是否正确。2单步决策和完整轨迹是否合理①单步评测在某个固定状态下问Agent 下一步该做什么适合快速验证工具选择、参数生成、是否应该向用户追问信息以及是否应该结束任务。②轨迹评测把整条工具调用序列拿出来看。根据任务定义三类约束哪些步骤必须出现哪些步骤禁止出现哪些步骤有先后依赖。剩下的路径允许 Agent 自己选择。不必迷信「理论最短路径」因为多一步验证可能换来更高安全性。效率应该在成功且合规的前提下比较。3端到端任务是否真的完成端到端评测把 Agent 当成一个整体核心指标是任务完成率也就是满足成功条件的任务数占全部评测任务的比例。关键「成功条件的定义」、对同一任务能否重复运行4线上业务是否得到改善用户和业务真的受益吗业务效果、延迟、Token、成本和安全。评测集与指标的设计1样本来源真实请求、边界场景、对抗与安全样本、历史 Badcase。①真实请求。对生产日志去除隐私信息后按任务类型、难度、工具、对话轮数和风险等级分层采样不能只抽最常见、最容易的请求。②边界场景。比如参数缺失、时间表达含糊、工具超时、返回空结果、上下文很长、多个工具都像能用。这些题不一定高频却最容易暴露工程问题。③对抗与安全样本。比如工具返回中藏着提示词注入用户要求越权读取数据或者诱导 Agent 绕过确认流程。它们用来检验安全边界而不是追求平均体验分。④历史 Badcase。线上每出现一种新的失败模式人工确认原因后就把有代表性的样本加入回归集。这样评测集不是一次性作业而是在记录系统真实踩过的坑。2指标评分设计确定性检查、人工评审和 LLM-as-a-Judge 三者组合使用。①确定性检查应该优先使用。 参数能否通过 Schema、是否调用禁用工具、数据库最终状态是否正确、代码是否通过测试这些都可以由程序直接判断。它速度快、成本低、结果稳定也最适合放进持续集成。②人工评审负责定义标准和处理高风险歧义。 领域专家适合判断政策是否遵循、开放式结果是否有用也适合审查自动裁判分歧大的样本。人工不一定要评全部数据更重要的是建立清楚的 Rubric并持续抽查自动评测是否跑偏。Rubric 评分标准表③LLM-as-a-Judge 负责扩展开放式评测。 例如报告是否完整、回复有没有解决问题、整条轨迹是否合理很难用字符串匹配判断这时可以让大模型按 Rubric 输出结构化分数和理由。3产品发布“门禁”很多团队最后会做一个综合分但综合分不能解决所有决策。更合理的做法是先设硬门禁再看质量与效率。安全违规、越权动作、绕过必要审批、重复产生严重副作用这些样本只要失败就应该阻止发布。对于普通质量指标再根据业务目标比较任务完成率、轨迹质量、延迟和成本。