1. 问题

记忆系统是怎么设计的？长短期记忆都在什么情况下存入数据库，短期记忆的摘要是怎么做的？

1. 回答

我把记忆分成短期记忆和长期记忆。短期记忆保当前会话里的关键信息，比如用户目标、已确认槽位和待确认问题，一般在轮次结束、状态变化或上下文快满时做结构化摘要后入库；长期记忆只存稳定、可复用、经过确认的用户画像，比如预算、偏好和常用场景，只有在信息重复出现、用户明确确认或置信度足够高时才写入数据库。短期摘要我通常保留五项：目标、已确认、未确认、当前阶段和风险点。

2. 问题

讲下 ReAct 和 Plan-and-Execute，分别适用于什么场景？

2. 回答

ReAct 是边推理边调用工具，适合步骤少、需要实时反馈的场景，比如简单检索、客服咨询和快速试错的工具调用；Plan-and-Execute 是先规划再执行，适合步骤多、需要全局拆解的复杂任务，比如长任务处理、多步工作流和统一调度的 Agent 系统。简单任务我更倾向用 ReAct，复杂任务我更倾向用 Plan-and-Execute。

3. 问题

讲下基于 LangGraph 构建状态编排器，节点是怎么定义的，edge 是怎么定义的？

3. 回答

我把 LangGraph 理解成一个有状态的图编排器，核心就是 State、Node 和 Edge 三部分。State 是共享状态，里面放 messages、用户画像、检索结果、工具结果这些流程中要传递的数据；Node 是处理状态的函数，每个节点只负责一件事，比如意图识别、知识检索、工具调用、答案生成或摘要更新；Edge 决定节点之间怎么流转，普通 edge 负责固定顺序执行，conditional edge 则根据当前 state 里的结果动态决定下一步走哪条分支。这样做的好处是流程清晰、可以分支回环，也方便做 checkpoint 和中断恢复。

4. 问题

ReAct 中执行出错了怎么处理？

4. 回答

我一般会把执行错误分成两类处理：一类是工具或调用层错误，比如超时、返回空值、参数不合法，这种我会先让模型重试一次或者走降级工具；另一类是任务理解错误，比如选错工具、走错路径，这种我会把错误结果作为 observation 回传给模型，让它根据反馈重新决策。如果连续失败或触发最大重试次数，就直接转人工或者走兜底回答，避免 Agent 一直空转。

5. 问题

如果有非常多个工具，怎么保证 LLM 不会调用错？

5. 回答

我一般不会把所有工具一次性都暴露给模型，而是先做工具分层和路由，只给它当前场景真正相关的一小组工具；同时会把工具名、描述和参数 schema 设计得非常清楚，尽量减少歧义。执行时再加一层参数校验和结果回传，如果模型选错了工具，就把错误原因反馈回去让它重新选；如果工具数量特别多、路径特别复杂，我会先做规划再执行，或者引入路由层、意图分类和白名单机制来缩小可选范围，避免模型乱选。

6. 问题

PostgreSQL 的表是怎么设计的？

6. 回答

我一般会先按业务对象和访问路径来设计表，而不是先按功能堆字段。核心思路是把数据分成主表、明细表、状态表和日志表：主表存稳定实体，比如用户、会话、任务；明细表存一对多内容，比如消息、检索结果、工具调用记录；状态表存当前进度和可恢复信息；日志表存审计、异常和操作轨迹。设计时会重点考虑主键、外键、唯一约束、索引、分区和幂等写入，保证既能查得快，也能支持后续的状态恢复、回流和审计。

7. 问题

RAG 的 embedding 模型为什么选 bge-large-zh？

7. 回答

我一般会选 bge-large-zh，主要是因为它对中文语义检索效果比较稳，尤其适合中文客服、知识库和问答类场景。它的优点是中文理解能力强、向量质量比较稳定，和后面的向量召回、Rerank 能比较好地配合；同时它在工程上也比较成熟，和常见的向量库、检索链路集成成本低。实际选型时我会优先看召回质量、中文效果、吞吐和成本，bge-large-zh 在这几个维度上通常比较均衡。

8. 问题

为什么设计强弱模型协同流转机制？

8. 回答

我设计强弱模型协同流转，核心是为了在效果、成本和延迟之间做平衡。简单任务其实不需要一直调用大模型，用弱模型就能完成的就先让弱模型处理，比如分类、抽取、简单改写和常规问答；只有遇到复杂推理、高风险决策、长上下文理解或低置信度场景时，再升级到强模型。这样做的好处是既能保证关键任务的质量，又能把整体推理成本、TTFT 和资源占用降下来，同时也方便按场景做路由和降级，避免所有请求都走最贵的链路。

9. 问题

讲一下对 Harness 的理解。

9. 回答

我理解 Harness 本质上是一个 Agent 运行时底座，它的核心不是把 prompt 拼起来，而是把模型、工具、状态和执行流程解耦出来，让 Agent 能稳定地跑起来。它一般会把 LLM、Tool、Loop、Memory 这些能力抽象成统一接口，新增模型或者新增工具时不用改主流程；同时还会把执行过程做成可观测、可恢复、可重试的状态机，方便处理中断、回放和降级。对我来说，Harness 解决的是“怎么把 Agent 从一次性 demo 变成可维护、可扩展、可上线的系统”这个问题。

10. 问题

Multi-Agent 怎么设计，怎么通信？

10. 回答

我一般把 Multi-Agent 设计成主控 + 分工子 Agent的结构，先明确每个 Agent 的职责边界，比如规划、执行、审核、观察各自只负责一件事，避免职责重叠。通信上通常有两种方式：一种是通过共享状态或消息总线传递任务和结果，适合松耦合协作；另一种是通过显式的消息协议或函数调用来交接上下文，适合需要强控制的场景。实际落地时我会给每个 Agent 定义清晰的输入输出 schema、超时和重试机制，并且保留主控调度和人工兜底，防止多个 Agent 之间互相打架或者上下文污染。

11. 问题

并行 tool 和有依赖的串行 tool 都怎么设计？

11. 回答

我一般会把 tool 调用分成两类：可以并行的和必须串行的。能并行的 tool，前提是它们之间没有数据依赖，比如同时检索多个知识源、同时查用户信息和订单信息，这种我会让模型一次性发出多个 tool call，或者由编排器并发执行，再把结果统一汇总给模型；这样可以减少整体延迟。对有依赖的串行 tool，我会按 DAG 思路设计，前一个 tool 的输出作为后一个 tool 的输入，比如先抽槽位、再检索、再判断是否要追问或调用下一个工具，这种必须按顺序执行，不能并发。实际实现上我会给每个 tool 标清楚输入输出 schema 和依赖关系，能并行的就并行，必须串行的就走状态机或流程图控制，避免模型乱跳。

12. 问题

怎么评估 agent 成功率？

12. 回答

我一般不会只看“有没有回答”，而是看任务是否真正完成。评估上会拆成几类指标：第一类是任务成功率，也就是最终目标有没有达成；第二类是中间过程指标，比如工具调用是否正确、检索是否命中、是否发生了错误重试；第三类是体验指标，比如 TTFT、总耗时、转人工率和用户满意度。对于可自动判定的任务，我会用回归测试集和标准答案做离线评估；对于开放式任务，我会结合人工抽检、LLM judge 和线上 A/B，重点看成功率、转化率和失败原因分布。这样能把“模型说对了”和“业务真的做成了”区分开。

13. 问题

遇到过幻觉吗，如果有怎么减少？

13. 回答

遇到过。我的处理思路不是只靠模型自我纠错，而是从链路上去减少幻觉：一方面用 RAG 和工具调用把事实来源外置，能检索就不让模型凭空编；另一方面把高风险内容做规则校验、置信度阈值和转人工兜底，低置信度时宁可不答也不要乱答。同时在提示词上会强调只基于证据回答，输出结构化结果，必要时让模型先生成草稿再校验，减少它自由发挥的空间。
 

14. 问题

如果llm调用tool的时候，突然断网了，接口返回的成功，但是没有收到，再次启动会怎么样，这种要怎么处理？

14. 回答

这种情况本质上是 tool call 的状态不确定问题。企业级一般不会靠单次 HTTP 返回来判断成败，而是给每次工具调用分配唯一 id，把调用状态和结果持久化，工具本身也要做幂等。重启后先查 call 状态，如果是 unknown 或 running，就通过 id 去工具侧补查结果；如果确认没成功，再按幂等重试，避免重复副作用。核心是 at-least-once 语义加幂等兜底，而不是假设一次调用一定有且只有一次。