1、在 Agent 知识闭环中，如何设计，去决定哪些信息进入向量数据库（长期记忆），哪些进入上下文窗口（短期记忆），以及哪些直接转化为模型权重的元记忆

不是按内容类型分，而是按照具体的时效性、稳定性、调用频率、风险、可验证性分层

三层记忆的职责

• 上下文窗口（短期记忆）

  • 放的是当前任务完成所必须且必须被大模型逐token推理直接访问的信息，例如
  • 当前轮用户目标、约束、偏好
  • 最近若干轮高相关对话
  • 当前工具返回结果的关键信息
  • 当前计划、当前子任务状态
  • 影响下一步决策的失败轨迹

  不适合放入：

  • 很久以前但当前无关的历史
  • 可外部检索的长文档原文
  • 大量重复事实

• 向量数据库/GraphRAG/外部记忆（长期记忆）

  • 放的是未来可能复用，但不值得长期占用上下文窗口的信息

适合

• 用户长期偏好
• 历史人物结论
• 稳定领域知识的索引块
• 过去对话中抽取出的事实、事件、实体关系

向量库适合“可检索事实”，不适合直接存“任务控制状态机”。复杂依赖更适合图或结构化状态存储。微软 GraphRAG 的核心价值就来自把语料先组织成实体—关系—社区，再做全局与局部检索，而不是只做 chunk embedding

• 模型权重里面的“元记忆”

  这里不是在线即时写权重，而是通过微调 / 偏好训练 / policy 学习沉淀成行为先验。

  适合内化进权重的：

  • 工具调用风格：先检索再行动、先校验参数再提交
  • 规划范式：先目标分解再执行
  • 错误恢复习惯：超时重试、参数校正、fallback 路由
  • 澄清策略：信息不充分且高风险时优先追问
  • 某行业稳定规则：比如电商导购中的预算、库存、兼容性检查顺序

  不适合写进权重的：

  • 高频变化的事实
  • 某个用户的私有偏好
  • 某次任务的中间状态

2. 对话轮数极多、上下文严重不足时，如何在不丢失初始 Attention Sink 的前提下保持连贯性

不能把所有历史都压缩成摘要塞回去

要把内容分好主次，正常来讲要保证一个锚定前缀，初始 token 常形成 attention sink，即使语义未必重要，也会成为注意力稳定锚点；只保留滑动窗口会导致性能明显崩。保留开头 sink token 的 KV cache，可以显著恢复长流式生成能力

所以正常工程上可以保留三段

• Anchor Prefix：固定前缀锚点，比如系统指令、角色、核心规则、用户长期目标的极短版
• Active Working Set：当前任务相关上下文
• Recent Window：最近N轮对话

正常来讲，是“首部锚定+中间检索+尾部活跃窗口”

为什么这样有效

长上下文模型常见两类问题

• Lost in the middle：中间信息利用差
• Long-context ≠ long reasoning：即便上下文很长，也不代表模型能稳定做长程 in-context learning

因此保持连贯性不能靠单纯扩窗，而要靠

• 锚点稳定角色和目标
• 检索恢复远端的关键事实
• 最近窗口承接局部推理
• 显式状态机记录任务进度

常见策略

• 1、 Pinned Prefix/Frozen KV
  • 保留最初一小段系统前缀的kv，不参与淘汰
  • 通常适合：长会话客服/变成copilot/多轮导购Agent
• 2、分层摘要，而不是单层摘要
  • 不只保留全文摘要，还要做一些结构化的分层摘要
    • 比如全局背景/当前任务目标/约束/关键人物/商品/为什么做过某个决策/尚未完成的问题等
• 3、事件账本
  • 把每轮对话转成结构化事件
    • 用户新增约束
    • 工具返回事实
    • 计划改变
    • 错误与恢复
    • 最终结论
• 4、检索式回放
  • 不是把老内容塞进去prompt，而是在当前生成做
    • 目标检索
    • 实体检索
    • 决策检索
    • 失败经验检索

断点续写时如何保持一致

每次中断前保存

• 当前目标
• 当前计划树
• 已完成步骤
• 未完成步骤
• 最近一个可信工具结果
• 需要验证的点

3、如何设计一个agent，以及如何在“推理-行动”循环中纠正逻辑坍缩或无效工具调用

感知层

• 根据来源，例如用户文本/工具返回/页面上下文/历史记忆， 输出具体的意图，候选工具

规划层

• 输出一个显式的计划对象，而不是只是在隐式的CoT里面想

  Goal Subgoals[] Assumptions[] RequiredEvidence[] CandidateTools[] StopConditions[] FallbackPlan[]

执行层

• 每一步执行前都做校验， 比如参数校验/工具可用性校验/权限检查等

反思层

• 检查结果是否满足目标，工具输出是否符合预期，是否出现循环调用

如何解决逻辑塌缩

逻辑塌缩一般是指计划越来越短视、重复调用同一个工具但是没有信息增益，忽略前面的约束，工具失败后开始编造等等，或者为了流程往下走，私自把假设当作事实

因此可以考虑

• 每步都做好状态对账，比如
  • 当前目标是否变化
  • 是否违反了既定约束
  • 是否与工具返回冲突
• 引入信息增益阈值
  • 如果两次连续工具调用的信息增益低于阈值，强制更换工具、回退上一步、或者请求澄清
• 失败分类
  • 把失败情况分情况讨论，而不是直接一律重试
• 强制证据-结论绑定
  • 每个中间结论都要有依据，比如挂上来源工具、来源时间、可信度等
• 回退点
  • 对于关键节点设立checkpoint，若塌缩就回归…

4. MCP 与传统 Agent Skills 的区别是什么？如何在多智能体环境中动态发现并注册跨协议工具？

传统Agent Skill

• 更像是平台内部封装好的技能函数，通常绑定某个框架，生命周期、输入输出格式、发现机制都不统一

MCP

• 标准协议层，不是单个技能库，官方规范把服务器可暴露能力分成
  • Tools
  • Resources
  • prompts
• 客户端可以发现这些能力并且统一按照schema调用

动态发现和注册怎么做？

在多Agent环境里，可以考虑做个Tool Registry或者Capability broker

比如注册流程可以这么设计

• agent启动
• 向mcp server/skill registry等发discovery
• 规范化成统一的schema，再加入路由层

tips：

可以把不同协议都抽成一层接口，比如Capability

然后里面可以有很多类型，交给适配层去统一适配

如何动态发现

两级发现

• 系统启动时直接扫描所有已知服务
• 如果当前任务与已知的工具匹配度都不足，就触发新服务的探测啊之类的东西

跨协议注册的关键难点

1. schema 语义不一致
2. 相同工具不同版本冲突
3. 权限域不同
4. side effect 不透明
5. tool description 写得烂导致路由错误

解决：

• 统一 capability ontology
• 对 description 做重写与增强
• 做在线 health check
• 做 shadow eval
• 对写操作工具单独治理

5. 用户请求高度模糊，Agent 如何精准理解？

之前写过的文档里面有提到过

查询扩展、自查询等

6. 如何设计“主动澄清”决策逻辑？什么时候反问，什么时候结合历史强行推断？

首先的话肯定要分危险等级

相对高风险的情况可能有

• 涉及到高风险的写入操作，例如下单、支付等
• 缺少必要的slot信息槽信息
• 用户的信息是互相冲突的
• 跟用户画像冲突
• 跟敏感行业有关系，比如金融、药品等

可以直接推断的，比较低危险的情况

• 可能是一些简单推荐
• 或者就是符合历史用户画像
• 推断带来的后果很小之类的

7. 3 个以上工具调用且高频请求，怎么压低端到端延迟？

首先的话肯定是要判断延迟来自于哪里

• 思考轮次太多？
• 工具调用太多？
• schema太大，返回太长
• …

然后可以考虑针对性优化

• 工具并行
• 结果缓存
• 规则匹配，尽量避免llm参与