1、什么是 Agent？与大模型的区别？
传统AI（大模型）是对输入的文本，只依赖已拥有的信息，输出文字回答。
Agent能规划问题解决流程，调用外部工具，搜索未知信息，编写并执行代码，纠正问题，评审结果，输出结果。
重点：自主性、能动性。（比如你能让他帮你清日常）
2、Agent 的基本架构由哪些核心组件构成？
LLM（large language model）、工具、记忆、规划模块
LLM 是整个系统的大脑，负责理解任务和做决策；工具让 Agent 能跟外部世界交互，搜索、执行代码、调 API 都靠它；记忆让 Agent 在任务执行过程中保持状态，不会「失忆」；规划模块负责把复杂目标拆解成可执行的步骤。
3、Workflow，Agent，Tools
Tools 是最小的能力单元，就是封装好的可调用函数，比如搜索、执行代码、发邮件，它只负责「执行」，本身没有任何决策能力。
Agent 是一个完整的决策系统，内部用 LLM 做大脑，自己判断什么时候调哪个 Tool、要不要继续、什么时候结束，是主动的。
Workflow 是更上层的编排框架，把 Agent、LLM、Tools 组织成一条确定性流程，每个节点做什么、按什么顺序流转都是开发者事先写死的。
三者最核心的区别就一句话：Tools 不做决策只执行，Agent 自己做决策，Workflow 是开发者替所有节点把决策提前写好。
4、Agent 设计范式
ReAct、Plan-and-Execute、Reflection
ReAct ：Thought -> Action -> Observation 循环，「走一步看一步」，每一步都是局部最优决策。
Plan-and-Execute：规划和执行解耦，先做规划，输出一个完整的步骤列表，然后逐步执行；每执行完一步都会把结果反馈给规划器，规划器会判断是否需要更新计划。既保持了全局视野，又不会因为死板而失效。
Reflection：「质量保障」。在 Agent 完成一步或者完成整个任务之后，再判断做得好不好、结果是否符合预期。如果评估不通过，就重试或者换一种策略。这个机制能显著提升输出质量。
变体——Reflexion。不只是说「这个结果不好，重做一遍」，而是会生成一段具体的「反思总结」，记录下这次失败的原因和改进建议，然后把这段总结作为额外的上下文传给下一次尝试。
5、Agent 推理模式
CoT、ToT、GoT
（1）CoT，全称 Chain of Thought，两种触发方式。
Zero-shot CoT，直接在 prompt 末尾加上「让我们一步步思考」这句话就行了，零成本、即插即用，缺点是发挥不稳定。
Few-shot CoT，需要在 prompt 里给几个带有完整推理过程的例子，让 LLM 照着这个格式来模仿。LLM 会按照同样的格式展开推理。Few-shot 的效果更稳定，特别适合输出格式要求比较固定的场景，代价是需要你提前准备高质量的示例，而且示例本身也会占用 token。
（2）ToT ，全称是 Tree of Thoughts（思维树），针对的正是 CoT「一旦走错就全错」的问题。
核心改变是把「生成一条推理链」变成「同时探索多条推理路径，边探索边剪枝，最终选出最优路径」。
（3）GoT ，全称是 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）信息层
滑动窗口、摘要压缩、重要性过滤、结构化抽取。
时间维度：滑动窗口和摘要压缩解决「历史太长怎么截」，前者直接硬截，后者截之前先提炼；
内容维度：重要性过滤解决「内容不等价怎么挑」，打破时间顺序按价值保留；结构化抽取解决「对话文本是不是最佳载体」，换一种信息密度更高的形式存储。
（2）Prompt Caching
上面这些「信息层」的压缩策略，还有一个「计算层」技术叫 Prompt Caching。
背景：LLM 每次处理请求，都需要把输入的所有 token「过一遍模型」来做计算，这个过程叫 prefill，是延迟和成本的主要来源之一。常见的场景：一段固定的 system prompt 加上越来越长的对话历史，每次调用时这段历史都会被重新计算一遍，哪怕它和上一次调用时完全一样。
Prompt Caching 的思路：如果 prompt 的前缀部分在多次请求之间是一样的，就把这部分的计算结果缓存起来，下次请求如果前缀匹配，直接复用缓存，不重新计算。费用和延迟都大幅降低，某些场景下能降到原来的十分之一。
记忆压缩和Prompt Caching 可以同时使用，是互补关系，不是替代。
12、「手搓」Agent和成熟框架
（1）框架：用起来快，但有几个实际痛点。
第一是抽象层太多，调试的时候不知道哪步出了问题，得一层层往下扒；
第二是版本升级经常有破坏性变更，线上稳定性难保证；
第三是框架的通用设计往往和具体业务需求有偏差，定制起来反而更费劲。
（2）手搓：代码完全在自己掌控之内，可观测性好、出问题好排查，也更方便做性能优化。
所以策略是核心逻辑手写，只在边缘功能上用框架的工具。
13、如何赋予 LLM 规划能力
（1）CoT 是让 LLM 把推理步骤写出来，线性地一步步推导到答案；
（2）ToT 是让它同时探索多条推理路径，选最优的继续深入；
（3）GoT 是图结构推理，推理节点可以复用和合并，适合更复杂的任务。
用 CoT 最多，因为实现成本最低，就是改个 prompt；ToT 效果更好但调用次数多，成本大概是 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）产品发布“门禁”：
很多团队最后会做一个综合分，但综合分不能解决所有决策。
更合理的做法是先设硬门禁，再看质量与效率。安全违规、越权动作、绕过必要审批、重复产生严重副作用，这些样本只要失败就应该阻止发布。对于普通质量指标，再根据业务目标比较任务完成率、轨迹质量、延迟和成本。
