7.29 Agent八股学习+小程序学习

Agent八股学习

[Workflow，Agent，Tools 这三个的概念和区别介绍一下？](#Workflow，Agent，Tools 这三个的概念和区别介绍一下？)

[了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？](#了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？)

[Agent 推理模式有哪些？ReAct 是啥？具体是怎么实现的？](#Agent 推理模式有哪些？ReAct 是啥？具体是怎么实现的？)

[ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？](#ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？)

复杂任务怎么做的任务拆分？为什么要拆分？效果如何提升？

[Agent 的长短期记忆系统怎么做的？记忆是怎么存的？粒度是多少？怎么用的？](#Agent 的长短期记忆系统怎么做的？记忆是怎么存的？粒度是多少？怎么用的？)

[什么是 Multi-Agent](#什么是 Multi-Agent)

[说说 Single-Agent 和 Multi-Agent 的设计方案？](#说说 Single-Agent 和 Multi-Agent 的设计方案？)

小程序学习

[WXML 模板语法](#WXML 模板语法)

数据绑定

[target 和 currentTarget 的区别](#target 和 currentTarget 的区别)

事件绑定

[bindtap 的语法格式（tap事件）](#bindtap 的语法格式（tap事件）)

[在事件处理函数中为 data 中的数据赋值](#在事件处理函数中为 data 中的数据赋值)

事件传参

[bindtap 的语法格式（input 事件）](#bindtap 的语法格式（input 事件）)

[实现文本框和 data 之间的数据同步](#实现文本框和 data 之间的数据同步)

Agent八股学习

Workflow，Agent，Tools 这三个的概念和区别介绍一下？

面试官您好，区分 Tools、Agent、Workflow 最核心的标尺就一个：由谁决定下一步该做什么、往哪走，三者是从小到大、可以互相嵌套的三层结构，并不是互斥的三个选项，项目里一般是搭配使用的，我分层来讲。

先说最底层最小单元：Tools 工具 工具本质就是封装好、附带标准描述文档的普通函数，像联网搜索、代码执行、查询数据库、发送邮件都属于工具。它只有固定的入参和输出，完全没有一丁点决策能力，只会被动等着被调用，自己不知道什么时候该执行、该不该执行，好比瑞士军刀的各个刀片，刀片本身不会自己弹出来，只能被人选择使用。想要 LLM 正常调用工具，工具的描述必须精准单一、报错信息易懂、参数尽量精简；现在行业也在用 MCP 协议统一工具标准，一套服务对接所有智能体，不用重复写适配代码。

中间层是Agent 智能体，也就是拿着工具自主做判断的主体 Agent 内部是以 LLM 作为大脑，依靠 ReAct 思考 - 行动 - 观察 - 复盘的闭环自主运转。给到一个笼统目标，模型自己拆解步骤、自主挑选对应工具、根据返回结果修正方案，循环执行，直到模型判定任务结束。整个循环运行多少次、走哪条执行路径，开发者事前没法固定写死，是运行时动态生成的。不过线上环境不会放任 Agent 无限循环，必须配置四层停止保护：LLM 主动判定完成、最大循环次数、token 消耗上限、运行超时，任一条件触发立刻终止，防止卡死、成本失控。也正因为 LLM 是概率模型，相同任务多次运行路径可能不一样，结果存在不确定性，生产环境必须打印完整运行日志方便排查问题。 Agent 优势就是灵活性极强，擅长处理路径未知、需求开放、情况复杂的任务；缺点就是行为不可控、调试排查比较麻烦。

最上层的编排框架是Workflow 工作流 Workflow 是开发者提前用代码写死整套流程骨架，整个链路的走向、分支跳转全部靠代码的 if-else 逻辑管控。流程里的节点可以是普通 LLM 调用、可以是工具、也可以嵌入完整 Agent，节点只负责完成自身分内工作，没有权限决定流程走向。拿客服退款举例，Workflow 会固定死：意图识别→匹配退款分支→查订单→校验资格→提交退款→告知用户，每一步顺序、分支全是预先定义好的。它最大特点就是执行结果高度确定、行为可预测，线上出问题能够逐节点断点排查，稳定性高、成本和延迟都很好管控，特别适配标准化、重复固定的业务流程。

我再横向对比下三者关键差异：

决策主体：工具无决策；Agent 靠 LLM 动态实时决策；Workflow 由开发者代码提前固化决策
执行模式：工具被动调用；Agent 主动循环执行；Workflow 按预设顺序死板运行
确定性：工具输入固定输出就固定；Agent 随机性高；Workflow 全程可预知
调试难度：工具最简单，Workflow 易排查，Agent 最难复现问题
适用场景：工具用来封装零散能力；Agent 处理复杂开放任务；Workflow 承载标准化业务流程

最后结合工程落地来讲，纯 Agent 或是纯 Workflow 在正式线上项目都很少单独使用，现在行业主流方案是Agentic Workflow（智能工作流）。用 Workflow 锁住整体业务大框架，保障系统可控、方便运维排查；只在流程里需要灵活处理、需求多变的节点内嵌 Agent，兼顾稳定性和智能性。业界常用五种经典编排模式可以自由组合使用：第一种 Prompt Chaining 提示链，线性流水线执行，适合摘要、翻译这类有序步骤；第二种 Routing 路由分发，依靠 LLM 做分类，分流到不同业务分支，客服系统最常用；第三种 Parallelization 并行执行，多个独立子任务同步运行再汇总结果，提升处理效率；第四种 Orchestrator-Workers 编排者 - 工作者模式，总模块分发任务，多个子模块并行干活，适合大型复杂调研任务；第五种 Evaluator-Optimizer 评估优化模式，一份 LLM 生成内容，另一份 LLM 审核打分，不合格就迭代重写，对文案、代码、报告这类输出质量要求高的场景必不可少。

最后补充一下面试容易踩的坑：很多人误以为 Workflow 就是多个 Agent 串在一起，这个说法不对，Workflow 节点不限定为 Agent，LLM、工具都能作为节点，区分 Workflow 和 Agent 的核心从来不是节点类型，而是流程控制权在代码手里，还是在大模型手里。

了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？

首先是三种核心的 Agent 设计范式，分别是 ReAct、Plan-and-Execute、Reflection，三者还可以互相搭配使用。第一个是 ReAct 范式，也是最基础、落地最普遍的范式。核心就是推理结合行动，固定走 Thought 思考、Action 执行工具、Observation 接收结果这个循环。模型先显性写出思考逻辑，再依据思考结果选择工具调用，拿到返回数据之后再次判断后续动作。好处是架构简单、成本低，适配步骤少、相对独立的任务；短板是属于边走边决策的局部最优模式，处理长链路、多步骤的复杂任务时，很容易偏离最初目标、在流程里打转。

第二个是 Plan-and-Execute 规划执行范式，就是用来弥补 ReAct 长任务容易失控的问题。它将规划和执行两个环节彻底拆开，任务开始先由 LLM 生成一份完整的全局执行步骤清单，后续再依照这份计划分步执行。而且正规的实现都会加入动态重规划机制，每执行完一步拿到结果，规划模块就会核验执行效果，如果结果不符合预期、出现突发状况，就实时修改后续的执行方案，不会死板地照搬初始计划。优点是具备全局视角，复杂任务不容易跑偏；缺点是会多出规划、重规划的模型调用，带来更高的 token 开销与接口延迟，并且如果最开始的总体规划方向出错，后续所有执行流程都会受到影响。

第三个是 Reflection 反思范式，这里需要纠正一个常见误区，Reflection 并不是调试工具，而是嵌入在 Agent 正常运行链路里的正式优化机制。执行完毕后，会调用 LLM 对本次输出内容做评估校验，判定结果是否合格，不合格就重新执行优化。它还有一个进阶变体 Reflexion，不只是单纯重做任务，还会总结本次出错原因和优化方案，把这份反思记录当作经验存入上下文，辅助下一轮执行，能明显提升代码编写、文案撰写这类高标准场景的输出准确率。但它的短板十分明确，每增加一轮反思，就会新增一次 LLM 调用，直接拉高整体的 token 消耗和请求延迟，落地时必须在输出质量和使用成本之间做权衡取舍。

三种范式并不是互相排斥的，工程中经常组合使用：用 Plan-and-Execute 把控整体全局计划，每一个细分步骤内部依靠 ReAct 完成工具调用，在关键的结果产出节点叠加 Reflection 做质量校验。任务简单只用 ReAct 就行；复杂多阶段任务搭配规划执行方案；对结果准确度要求严苛的场景，再额外加上反思机制。

说完范式，我再讲一下 Agent 和 Workflow 最核心的区别，判断标准只有一个：到底是谁掌控流程走向、决定下一步要做什么。 Workflow 的所有执行步骤、分支跳转逻辑，都是我们开发人员提前在代码中硬编码写死的，依靠 if、else 这类代码逻辑管控流转。LLM、Agent、工具全都只是流程里普通的执行节点，没有权限改动整体流程。Workflow 运行行为高度确定、全程可预测，线上出现故障能够顺着链路逐节点排查，成本和延迟都很好管控，很适合售后审核、固定客服应答这类标准化、一成不变的业务流程；缺点就是灵活性很差，碰到预设之外的业务场景，很容易执行失败。

而 Agent 是把流程的全部决策权交给运行过程中的 LLM，我们只需要输入最终目标，什么时候调用工具、选用哪个工具、什么时候终止任务，全部由模型自主判断决定。优势就是灵活性极强，可以处理没办法提前预设执行路径的开放型、复杂任务；但缺点也很突出，LLM 属于概率模型，运行行为带有不确定性，相同的输入多次运行可能走出不一样的路径，线上问题很难复现定位，token 消耗也不可控。所以生产环境的纯 Agent 必须配置多层保护机制，依靠模型主动判定完成、最大循环次数、token 上限、运行超时四重规则，防止出现死循环、成本失控的问题。

简单给您对比一下两者核心维度：Workflow 由开发者做决策，运行确定性高，调试简单，适配固定业务流程；Agent 由 LLM 动态实时决策，运行随机性强，排查难度大，适配未知路径的复杂任务。

结合实际工程落地来讲，根据 Anthropic 给出的落地原则：能用 Workflow 解决的需求，就不要优先使用纯 Agent。线上生产环境里，系统的可控性远比智能灵活性更加重要，Workflow 稳定、易维护、成本可控的特性更贴合线上业务需求。当下行业最主流的落地架构是 Agentic Workflow，用 Workflow 锁住整体的业务主干流程，保证系统稳定方便运维；只在流程中需要灵活推理、无法固化逻辑的节点，嵌入 Agent 能力。既解决了纯 Workflow 过于死板的问题，又规避了纯 Agent 不可控、难排查的缺陷。整体选型要遵循由简到繁的阶梯：单次 LLM 调用 > 固定 Workflow > 工作流内嵌局部 Agent > 全流程纯 Agent，按需升级架构，不要过度设计。

最后补充一下面试容易踩的坑：第一，不能把 Reflection 当成调试手段，它属于运行时的正式优化环节，代价是延迟和 token 消耗上涨；第二，不要认为 Agent 优于 Workflow，Agent 本质是为了应对业务不确定性付出的成本开销，只有确实需要动态决策时才使用；第三，线上基本不会直接部署裸奔的纯 Agent，主流都是工作流结合局部智能体的混合架构。

Agent 推理模式有哪些？ReAct 是啥？具体是怎么实现的？

面试官您好，Agent 目前主流的推理模式主要分三种：直接推理、CoT 思维链、ReAct 推理行动模式，层层递进、每一种都在解决上一种的缺陷。

最基础的就是直接输出，模型不做任何中间推导，拿到问题直接出答案。优点快、成本低，但多步计算题、复杂推理题很容易出错，因为它的思考是隐式的，中间步骤没有沉淀，误差会悄悄累积。

第二种是 CoT 思维链，核心就是把模型隐式思考变成显式思考，让模型先一步步写出推理过程，再给出结论。原理很简单，LLM 是逐 Token 生成的，先写出来的推理步骤会进入上下文，成为下一步生成的依据，相当于笔算代替心算，大幅降低推理错误。

CoT 又分两种：Zero-shot 就是直接加一句"一步步思考"，零成本即用，但不稳定、容易跳步；Few-shot 是提前给几个带完整推理的示例，让模型固定格式输出，效果更稳，但会消耗更多 Token。不过 CoT 有一个致命短板，它只能纯文本推理，无法和外部世界交互，不能联网、不能查实时数据、不能执行代码，很容易产生幻觉，遇到时效性问题完全不够用。

所以行业主流用的是第三种：ReAct 模式，也是目前 Agent 落地最广的推理范式。

ReAct 全称 Reasoning + Acting，它在 CoT 纯思考的基础上，加入了真实的行动能力，核心就是一套闭环循环：Thought 思考 → Action 工具行动 → Observation 结果观察，反复迭代，直到模型判断任务完成。

我简单说下它的逻辑：Thought 负责分析现状、决策下一步该干什么；Action 把决策落地，调用搜索、计算、数据库这些外部工具；Observation 把外部真实结果回传给模型，让模型基于最新事实继续推理。相当于让模型一边思考、一边干活、一边接收反馈，解决了 CoT 没法用外部信息、容易幻觉的问题。

这里有个面试高频重点：ReAct 的循环不是模型自己跑的，是代码框架驱动的。模型每一轮只负责输出思考和要执行的工具，解析工具、执行调用、拼接上下文、判断终止，全部是我们代码控制的。

经典实现是靠 Prompt 约束输出格式，强制模型按 Thought、Action、Input 的结构输出，我们代码正则解析后执行工具。现在新版本模型基本都支持 Function Calling，直接结构化 JSON 调用，不用文本解析，稳定性更高，但底层的思考-行动-观察闭环逻辑是没变的。

不过 ReAct 在工程里有两个很典型的短板。第一个是循环漂移 ，它是走一步看一步的局部决策，没有全局规划，任务长了很容易被上下文里的无关信息带偏，忘掉初始目标。第二个是错误传播，它默认上一步的观察结果都是对的，一旦中间某一步工具返回错误，后续整条推理链全部出错，而且没有自我校验机制。

针对这两个问题，行业就衍生出了 Plan-and-Execute 模式。先全局规划、再分步执行，相当于先看地图再走路，解决 ReAct 乱跑漂移的问题。而且成熟的实现会带动态重规划，每执行完一步就校验结果，实时调整后续计划。

所以我实际开发里的最优搭配是：大模型做全局规划，小模型配合 ReAct 做分步执行，既不会跑偏，又能控制成本、保证灵活性，是目前生产环境最通用的工程方案。

ReAct、Plan-and-Execute、Reflection 三种范式有什么核心区别？实际项目中该如何选型？

面试官您好，我先梳理 ReAct、Plan-and-Execute、Reflection 三者的核心区别，再结合工程落地讲讲具体的选型思路，顺带补充动态重规划、Reflexion、成本开销这些实战要点。

先说三者本质定位与核心差异。ReAct 和 Plan-and-Execute 属于完整的任务执行范式，决定整个 Agent 从头到尾的运行流程；Reflection 并不是一套独立的运行框架，是叠加在前两种范式之上的质量校验、修正增强能力，相当于给整套流程加一层质检 buff。

第一，ReAct 范式，模式就是边走边决策，依靠「思考 - 行动 - 观察」闭环迭代执行，规划和执行同步进行，不会预先产出全局步骤清单。就像外卖骑手送货，依据当下路况实时调整路线，灵活性拉满，代码实现简单、链路透明好排查。但短板很突出，长链路任务容易出现目标漂移，还会产生错误传导问题，前面步骤数据出错，后续整条推理链都会失效；并且每轮执行都要携带全部历史上下文，步骤越多 token 消耗上涨越快。适配场景大多是简单问答、实时信息检索这类步骤少、边界模糊的任务，也是新手上手最友好的范式。

第二，Plan-and-Execute 范式，核心是把规划、执行两个模块彻底解耦，先由规划器输出一份完整的全局执行方案，再交由执行器分步落地，类似项目负责人先出完整开发方案，开发人员依照方案干活。标准实现都会配套动态重规划机制，每完成一个步骤就核验执行结果，遇到意外情况实时修正剩余计划，解决了 ReAct 容易跑偏的痛点。工程里还有一个很实用的优化方案：规划使用推理能力更强的大模型，执行环节换成低成本小模型，能大幅削减整体调用成本。不过这套方案灵活度偏弱，面对突发场景容易卡顿，整体架构开发复杂度更高，也会多出规划阶段的模型调用开销。适合长链路、结构复杂的任务，像是行业调研、完整报告撰写、多工具协同数据分析这类场景。

第三，Reflection 反思范式，本身无法独立运行，依附于前两种范式使用。作用就是在步骤执行完毕或者整体任务结束后，调用模型自主评估输出内容，发现漏洞、错误就重新迭代优化。进阶的 Reflexion 机制更进一步，不光重做内容，还会整理出错原因、整改方案存入记忆，形成错题本，后续同类任务可以规避过往问题，在代码生成场景里能够明显拉高通过率。它的弊端十分直观，每多一轮反思就要新增 LLM 调用，token 开销、接口延迟都会上升，不加轮次限制还会陷入无限重试的死循环。只适合代码编写、商业文书、合规报告等对内容严谨度要求极高的业务场景。

顺带对比三者的 token 成本：同等 5 步工具调用的前提下，ReAct 上下文持续累加，token 开销线性暴涨；Plan-and-Execute 仅规划、汇总两处产生大额消耗，配合大小模型分层调用，总成本能省下一半以上；叠加 Reflection 之后，整体成本还会上浮三成到一倍，一般我们工程中会限制最多两次反思重试，控制成本阈值。

接下来说实际项目里的选型逻辑，整体遵循由简到繁、拒绝过度设计的原则。如果任务流程简短、需要灵活实时响应，优先直接使用原生 ReAct 快速落地验证功能；如果任务步骤多、链路长，很容易出现执行跑偏的情况，选用 Plan-and-Execute，同时开启动态重规划应对突发状况，搭配大模型规划、小模型执行的方式管控花费；如果业务对输出精度、正确率要求严苛，就在现有 ReAct 或者 Plan-and-Execute 基础上，叠加 Reflection 机制，必要时采用 Reflexion 沉淀错误经验。

线上生产环境最普遍的混合架构是：外层依靠 Plan-and-Execute 锁定全局大方向，保证整体流程可控不跑偏；每个子步骤内部用 ReAct 完成精细化工具调用，适配单步的动态需求；最终交付成果增加一轮 Reflection 做质量把关。

最后说下开发的落地顺序，先用 ReAct 跑通基础业务流程，根据真实的耗时、token 消耗数据，再按需升级为规划执行架构，精度不够再补充反思模块，不要一开始就堆砌所有机制，造成系统冗余、维护困难。

复杂任务怎么做的任务拆分？为什么要拆分？效果如何提升？

面试官您好，在处理 LLM 复杂任务时，我们核心的解决手段就是任务拆分。我从拆分原因、两种拆分方式、工程优化手段、最终提升效果四个方面来讲。

首先，为什么一定要做任务拆分 ？根本原因是 LLM 的上下文窗口和即时推理能力是有限的。如果直接把一个超大、超多步骤的复杂任务丢给模型一次性完成，模型会同时堆积大量中间状态，很容易出现跳步骤、遗忘前置条件、逻辑混乱、幻觉增多的问题。把大任务拆成一个个原子化小步骤，每一步只专注做一件事，模型注意力集中、上下文干净，推理准确率会大幅提升。而且拆分之后，每一步都能独立执行、独立校验、独立重试，不用整段重跑，排查问题也非常精准。

其次，任务拆分主要分为静态拆分和动态拆分两种 。第一种是静态拆分，属于人工预设的 Workflow 模式。我们提前根据业务经验，把整个任务的步骤、顺序、流程分支全部写死。优点是确定性极强、稳定、好调试；缺点是死板，只能处理预设场景，遇到未知情况容易卡住。适合固定标准化业务。

第二种是动态拆分 ，也就是 Plan-and-Execute 的核心逻辑。交给 LLM 做全局规划，模型根据当前任务目标，实时拆解出最合适的分步执行计划，再按计划逐步执行。而且成熟的动态拆分不是一次性拆完就结束，会带动态 Replan 重规划机制。每执行完一步，模型会根据最新结果判断原有计划是否还合理，如果出现意外、数据异常、场景变更，会实时更新剩余步骤，避免死守过时计划。灵活度很高，适配复杂多变的任务，但缺点是规划质量不稳定，初始规划出错，后续全部受影响。

工程里我们还会用自适应拆分优化：简单步骤直接执行，执行失败、质量不达标的复杂子任务，再递归二次细拆，做到难任务细拆、易任务简跑，避免过度拆分浪费资源。

拆完步骤之后，最重要的优化就是梳理步骤依赖、做并行执行 。我会把步骤梳理成 DAG 有向无环图，区分强依赖步骤和无依赖步骤。有依赖的串行执行，完全独立的步骤直接并发执行。这个优化效果非常明显，不是缩短单步耗时，而是压缩整体关键路径时长，线上真实场景能直接降低 40%--60% 的端到端延迟，步骤越多，提升越明显。

最后，拆分的质量有明确验收标准 ，我实际开发中会严格把控三点：第一是完备性 ，所有子步骤拼起来能完整覆盖主任务，没有遗漏需求；第二是独立性 ，每个步骤边界清晰、职责单一，没有任务重叠、重复劳动；第三是可验证性，每一步都有明确验收标准，支持自动校验、自动重试。

整体总结一下任务拆分带来的最终效果提升 ：第一，推理准确率大幅提升 ，解决了模型一次性处理复杂任务容易混乱、出错、失忆的问题；第二，系统可控性变强 ，问题可定位、可重试、可追溯；第三，执行效率显著提升 ，通过并行执行大幅降低整体耗时；第四，成本更可控，粒度适中的拆分避免超大上下文堆积，减少无效 Token 消耗。

所以生产环境复杂 Agent 任务，基本都是静态兜底 + 动态规划 + 并行优化的组合方案，兼顾稳定、灵活和性能。

Agent 的长短期记忆系统怎么做的？记忆是怎么存的？粒度是多少？怎么用的？

面试官您好，Agent 整套记忆体系主要分为短期记忆、长期记忆两层，两层各司其职、相互配合，解决 Agent 单次任务失忆、跨会话没有记忆积累两大核心痛点，我分开说明落地实现、细节优化以及整体协作流程。

先说短期记忆 ，它本质就是 LLM 的上下文窗口，等同于模型处理当前任务的临时工作台，里面存放本轮全部对话、思考过程、工具返回数据、每一步执行中间状态。代码层面就是维护一份 messages 消息列表，全程追加所有交互内容，每次调用大模型都会把完整上下文传入，以此保证任务执行连贯不会断片。但它有明显短板，上下文存在长度上限，对话越长越早的内容会被截断，而且单次任务结束之后数据直接清空，新会话不会保留任何历史信息。这里还有一个进阶优化方案：结构化工作记忆。原生的消息列表数据杂乱堆砌，结构化记忆会把工作台划分固定区域，分开存放任务目标、已验证结论、待确认假设，执行中实时更新、清理无效信息，即便对话很长，模型拿到的状态数据也是整洁精准的，不会被冗余历史内容干扰。

然后是长期记忆 ，专门补齐短期记忆无法跨会话留存数据的短板，整套依靠 Embedding 向量编码 + 向量数据库实现存储与检索。存入时把文本转为高维向量，语义相近的内容，向量在空间中的距离就更近；读取时将用户当前请求同样向量化，依靠向量库的相似度匹配做语义召回，不用依赖死板的关键词匹配，匹配精度更高，搭配 HNSW 这类索引结构还能保障检索速度。长期记忆内部还能细化成三类：语义记忆存放客观事实、用户基础信息；情节记忆记录过往完整的事件处理经历；程序记忆沉淀处理任务的固定流程、行为习惯。分开存储之后，检索时按需调取对应类型记忆，召回的有效信息质量会高很多。落地存储时还要把控记忆粒度，不能拆分得过碎，不然记忆碎片化、检索信息不全；也不能整段大批量存储，会混入大量无用内容干扰模型。工程里最优方案是以一次完整交互、单个独立关键事件作为存储单元。同时还要做记忆衰减处理，给历史数据加上新鲜度权重，老旧信息降低排序优先级，也可以定期清理、合并矛盾失效记忆，防止记忆库堆积无效脏数据。

接下来讲两层记忆真实的协同工作流程。任务正式发起前，先用用户需求检索长期记忆，把匹配到的用户偏好、过往经验注入系统提示词；任务运行全程依靠短期记忆承载所有执行状态，保证多步骤流程不会跑偏、遗忘进度；整项任务执行完毕，筛选本次产生的重要结论、用户习惯更新至长期记忆持久保存。两套模块一前一后配合，既保障单次复杂任务平稳跑完，又能让 Agent 跟着使用不断积累用户信息与处理经验。

最后说下开发里容易踩的三个误区：第一，不少人误以为长期记忆能用普通数据库关键词查询，实际核心是向量语义检索；第二，盲目拆分记忆颗粒度，过细过粗都会影响使用效果；第三，混淆两层记忆的运行阶段，短期记忆只存活在单次会话中，长期记忆负责事前召回、事后落地存储。

什么是 Multi-Agent

面试官您好，相比于单智能体，Multi‑Agent 多智能体系统，是我们处理超复杂、长流程、高专业度任务的核心方案。

首先，我先讲清楚为什么单 Agent 扛不住复杂任务 ，它有两个无法规避的硬瓶颈。第一是上下文窗口限制 。复杂任务的搜索资料、中间推理、多轮工具结果全部堆在上下文里，很容易塞满、早期信息被截断，导致 Agent 中途失忆、逻辑断裂，这是硬件级的硬限制，单纯调 Prompt 优化解决不了。第二是单点能力混杂。单 Agent 需要同时兼顾搜索、分析、写作、评审、编码各种工作，职责混杂、注意力分散，没有专精领域，每一块都做不精，而且一旦某一步出错，整条链路卡死，排查和容错都很差。

所以多智能体的核心思路就是专业分工、团队协作、解耦隔离。我们不再让一个 Agent 包揽所有工作，而是按职能拆分角色，每个 Agent 只负责单一专项工作，上下文完全独立、职责纯粹、专业度更高。

工程落地里，多智能体主要有三种标准协作模式。

第一种是顺序流水线模式，也就是串行执行。上一个 Agent 的输出作为下一个 Agent 的输入，像工厂流水线一样依次加工。适合有强依赖、流程固定的标准化任务，比如资料采集→内容整理→报告撰写→最终校对，优点链路清晰、可追溯、稳定可控，缺点没法并行，整体耗时偏长。

第二种是并行扇出模式 。由调度 Agent 把多个无依赖的独立子任务，同时分发多个工作 Agent 并行执行，最后统一汇总结果。比如同时调研多家竞品、多维度数据采集、多视角分析，都可以并发跑。这个模式能大幅压缩端到端延迟，整体耗时只取决于最慢的子任务，是多智能体性能提升最核心的手段，代价是同时调用多个模型，Token 成本会变高。

第三种是辩论评审模式。让多个 Agent 独立对同一个问题输出结果，互相质疑、交叉校验、对抗辩论，最后收敛出最优答案。非常适合高严谨性场景，比如代码评审、合同审核、方案选型、专业报告纠错，能极大减少模型幻觉，显著提升输出质量。

在系统架构上，业内主要分中心化和去中心化 两种。生产环境我们基本优先用中心化调度架构，由一个总指挥 Agent 统一拆任务、分配角色、管控流程、汇总结果，逻辑清晰、问题好定位、可控性强；去中心化是 Agent 自主协商通信，更灵活但不可控、难排查，线上很少用。

框架层面，现在主流成熟方案是 CrewAI、LangGraph ，开箱即用，封装好了调度、通信、汇总能力。另外微软最新整合了 MAF 框架，合并了 Semantic Kernel 和 AutoGen，是企业级生产环境的优选方案。

最后总结多智能体带来的实际效果提升：第一，彻底突破单 Agent 上下文限制，超大信息量任务不会失忆；第二，角色专业化，每个 Agent 专注单项工作，输出精度和专业度大幅提升；第三，支持并行执行，大幅降低整体任务延迟；第四，任务解耦、故障隔离，出问题可以精准定位对应角色，系统稳定性、可维护性远优于单 Agent。

所以复杂长流程、多维度、高专业度的生产任务，我都会优先采用多智能体分工协作的方案。

说说 Single-Agent 和 Multi-Agent 的设计方案？

面试官您好，我分开讲解 Single-Agent、Multi-Agent 两套设计方案，同时结合工程落地选型、架构差异、实践经验一并说明。

首先先说Single-Agent 单智能体设计方案 它的底层架构很简单，就是单个大模型搭配一组工具，依靠固定的循环逻辑运行：模型判断执行动作、调用对应工具、接收返回结果，反复迭代直到任务结束。整套代码集中在一处编写，整条执行链路清晰直观，排查报错、日常维护成本都很低，而且不存在 Agent 之间的通信开销。但单智能体存在两个硬性短板：一是复杂任务海量数据会塞满上下文窗口，模型容易丢失前置信息、出现失忆问题；二是一个 Agent 包揽搜索、编码、写作、评审全部工作，各项能力都做不到专精，另外独立子任务只能串行执行，整体耗时更长。所以 Single-Agent 只适合流程固定、体量适中、步骤不多的常规任务，没必要一上来就堆砌复杂的多智能体架构，避免过度设计。

其次是Multi-Agent 多智能体设计方案，整体分为中心化 Orchestrator 调度、去中心化 P2P 对等通信两种拓扑结构。

第一种：中心化 Orchestrator 调度方案，也是我项目里最常用的方案

整个系统分为调度 Orchestrator 总指挥 和Worker 执行员工两类角色。Orchestrator 不参与具体业务干活，只负责三件核心工作：拆解整体目标、把子任务分配给对应 Worker、收集所有结果整合输出最终内容。 Orchestrator 还分三层实现形态：静态路由依靠人工提前写死分发规则，逻辑最简单稳定；动态规划由 LLM 实时生成执行计划，适配大部分复杂业务；自适应编排会根据 Worker 的返回数据动态修正计划，能力最强但调试成本偏高，日常开发选用动态规划基本就能满足需求。各个 Worker 只处理分配给自己的专属任务，不用关心全局流程与其他 Agent 状态，每个智能体上下文相互隔离、数据干净，专业度和输出质量都会更高，无依赖的子任务还能由调度器扇出并行执行，大幅缩减整体耗时。出问题时可以顺着调度记录精准定位故障对应的 Worker 模块，链路可追溯、系统可控性强，是线上生产环境的主流选择。

第二种：去中心化 P2P 对等通信方案

这套架构没有统一总指挥，所有 Agent 依靠消息队列自主协商、点对点直接交互，纸面灵活性很高，但落地问题非常多。会出现任务重复执行、任务执行时序混乱、程序异常无法感知、没人校验整体任务是否完成等一系列问题，就像没有管理者的团队，协作效率低下还极易产出残缺结果。因此该方案大多只用于学术研究，正规工程项目基本不会落地使用。

接着讲项目里的选型策略与落地技巧 第一遵循渐进式演进思路：项目初期先用 Single-Agent 快速落地跑通业务，等到出现上下文溢出、模块输出质量差这些真实瓶颈时，再把对应模块拆成独立 Worker，不用一开始就搭建复杂的多智能体集群。第二顺带提一下行业最新的 A2A 通信协议，由谷歌推出并交由 Linux 基金会托管，用来统一不同框架、不同团队开发的 Agent 之间的通信标准，解决异构 Agent 互相调用的壁垒。不过目前协议还处于发展阶段，现阶段仅作技术储备，现有业务还是依托框架原生通信逻辑开发即可。

最后简单总结三者的核心区别：Single-Agent 架构最简、易维护，适配普通常规任务；中心化多智能体分工明确、支持并行、方便排错，是复杂业务的最优解；去中心化方案灵活度高，但可控性太差，工程实用性很低。面试里最容易踩坑的两点，一是不能单纯任务复杂就无脑上多智能体，要依据上下文压力、专业分工、并行需求三个真实条件判断；二是必须说清去中心化好看不好用的底层原因，不能只片面夸赞它的灵活性。

小程序学习

WXML 模板语法

数据绑定

动态绑定内容

html 复制代码

<!--pages/page/page.wxml-->
<view>{{info}}</view>
<view wx:for="{{msgList}}" wx:key="index">
  {{item.msg}}
</view>

javascript 复制代码

// pages/page/page.js
Page({
  /**
   * 页面的初始数据(data节点)
   */
  data: {
    // 字符串类型的数据
    info: 'init data',
    // 数据类型的数据（数组）
    msgList: [{msg: 'hello'}, {msg:'world'}]
  },
})

动态绑定属性

html 复制代码

<!--pages/page/page.wxml-->
<image src="{{imgSrc}}"></image>

javascript 复制代码

// pages/page/page.js
Page({
  /**
   * 页面的初始数据(data节点)
   */
  data: {
    imgSrc: "http://www.itheima.com/images/logo.png"
  }
})

三元运算

html 复制代码

<!--pages/page/page.wxml-->
<view>{{ randomNumber >= 5 ? '随机数字大于或等于5' : '随机数字小于5'}}</view>

javascript 复制代码

// pages/page/page.js
Page({

  /**
   * 页面的初始数据(data节点)
   */
  data: {
    randomNum: Math.random() * 10 // 生成 10 以内的随机数
  }
})

算数运算

html 复制代码

<!--pages/page/page.wxml-->
<view>生成100以内的随机数：{{randomNum * 100}}</view>

javascript 复制代码

// pages/page/page.js
Page({
  /**
   * 页面的初始数据(data节点)
   */
  data: {
    randomNum: Math.random().toFixed(2) // 生成一个带两位小数的随机数
  }
})

target 和 currentTarget 的区别

target 是触发该事件的源头组件，而 currentTarget 则是当前事件所绑定的组件。

在下面这个例子中，点击绿色按钮，点击事件以冒泡的方式向外扩展，也会触发外层 outer-view 的 tap 事件处理函数。因此对于外层的 outer-view 来讲：

e.target 指向的是触发事件的源头组件，因此，e.target 是内部的按钮组件
e.currentTarget 指向的是当前正在触发事件的那个组件，因此，e.currentTarget 是当前的 outer-view 组件

事件绑定

bindtap 的语法格式（tap事件）

小程序通过tap事件来响应用户的触摸行为：

html 复制代码

<!--pages/page/page.wxml-->
<view class="outer-view" bindtap="otherhandler">
  <!-- 通过 bindtap，可以为组件绑定 tap 触摸事件 -->
  <button type="primary" bindtap="btnTapHandler">按钮</button>
</view>

javascript 复制代码

// pages/page/page.js
Page({
  /**
   * 在页面的 .js 文件中定义对应的事件处理函数
   * 事件参数通过形参 event（一般简写成 e） 来接收
   */
  btnTapHandler(e) { // 按钮的 tap 事件处理函数
    console.log(e); // 事件参数对象 e
  }

css 复制代码

/* pages/page/page.wxss */
.outer-view {
  background-color: lightgreen;
  height: 100px;
  /* 开启弹性布局 */
  display: flex;
  /* 水平居中 */
  justify-content: center;
  /* 垂直居中 */
  align-items: center;
}

在事件处理函数中为 data 中的数据赋值

通过调用 this.setData(dataObject) 方法，可以给页面 data 中的数据重新赋值。下面这个例子每点击一次就增加1：

html 复制代码

<!--pages/page/page.wxml-->
<view class="outer-view" bindtap="otherhandler">
  <!-- 通过 bindtap，可以为组件绑定 tap 触摸事件 -->
  <button type="primary" bindtap="changeCount">{{count}}</button>
</view>

javascript 复制代码

// pages/page/page.js
Page({
  data: {
    count: 0
  },
  // 修改 count 的值
  changeCount() {
    this.setData ({
      count: this.data.count + 1
    })
  }
})

事件传参

html 复制代码

<!--pages/page/page.wxml-->
<view class="outer-view" bindtap="otherhandler">
  <!-- 可以为组件提供 data-* 自定义属性传参，其中 * 代表的是参数的名字 -->
  <button bindtap="btnHandler" data-info="{{2}}">事件传参</button>
</view>

javascript 复制代码

// pages/page/page.js
Page({
  btnHandler(e) {
    // 在事件处理函数中，通过 event.target.dataset.参数名 即可获取到具体参数的值
    const info = e.currentTarget.dataset.info;
    console.log(info)
  }
})

bindtap 的语法格式（ input 事件）

在小程序中，通过 input 事件来响应文本框的输入事件：

html 复制代码

<!--pages/page/page.wxml-->
<!-- 通过 bindinput，可以为文本框绑定输入事件 -->
<input bindinput="inputHandler"></input>

javascript 复制代码

// pages/page/page.js
Page({
  inputHandler(e) {
    console.log(e.detail.value)
  }
})

实现文本框和 data 之间的数据同步

html 复制代码

<!-- pages/page/page.wxml -->
<!-- step2 渲染结构 -->
<input value="{{msg}}" bindinput="iptHandler" />

javascript 复制代码

// pages/page/page.js
Page({
  data: {
    msg: 'hi'   // step1 定义数据
  },
  iptHandler(e) {
    this.setData({
      msg: e.detail.value // step4 绑定 input 事件处理函数
    })
  }
})

css 复制代码

/* pages/page/page.wxss */

/* step3 美化样式 */
input {
  border: 1px solid #eee;
  padding: 5px;
  margin: 5px;
  border-radius: 3px;
}