AI Agent全栈架构

主题

上下文调度思考 ​

1. 为什么 Agent 系统需要上下文调度 ​

想象你要写一份产品方案，材料堆了一桌子：任务说明、项目规则、历史优质方案、产品文档、论文、会议纪要、竞品页面、数据表，还有上一轮的审稿意见。

如果把这些材料全部塞进一个 Prompt，就像让一个人一边读完整本手册，一边写方案，还要一边审稿。结果往往是：

  1. 窗口有限：上下文窗口再大，也装不下长项目累积的全部资料。
  2. 注意力稀释：关键信息被埋住，互相冲突或缺少来源标签时，模型更容易漏掉事实。
  3. 成本延迟上升：每次调用都重复塞入手册、长文档和历史产物，会让每个 Agent 变慢、变贵。
  4. 职责混在一起：目标解析需要对象和场景；事实核查需要来源和引用；风格 Agent 需要规则和禁用词。让它们读同一包材料，容易跑偏。

上下文调度处理的就是这层材料分发：每次调用前，决定哪些信息进入本次 Prompt，哪些进入长期知识库，哪些只作为核查或验收依据。并且输出要正确写回产物、来源卡片或审稿记录。

一句话理解：上下文调度就是给每个 Agent 挑对材料、留够空间、记下出处。

2. 五类上下文 ​

可以把 Agent 系统里的信息分成五类，就像厨房里不同食材要放在不同柜子里。

2.1 本次任务上下文 ​

这是当前 run 必须使用的信息，来自用户最新指令、目标产物和工作流状态。

例如：

  • 当前要改的是结构、摘要、正文、引用还是格式。
  • 目标长度、语种、交付场景、截止时间。
  • 用户刚指定的限制，例如「不要改配置文件」「只处理第二节」。
  • 当前产物版本和本轮 diff。

这类信息优先进入 Prompt，决定本次调用的边界。任务结束后，大部分写入项目日志或审稿记录，不需要都进长期知识库。

2.2 长期知识库 ​

长期知识库存放跨任务复用的资料。它更像可检索资料库，不适合每次完整塞给模型。

适合存进去的内容：

  • 产品功能说明、术语表、FAQ、架构文档。
  • 公开论文、官方文档、规范和版本说明。
  • 会议纪要、用户研究摘要、历史选题库。
  • 已发布产物和复盘结论。

入库前要补齐来源、时间、适用范围和可信度标签。Agent 检索到片段后，也要带着出处进入 Prompt。避免把「模型记得某个说法」误当成「有来源支持」。

2.3 项目规则与风格约束 ​

项目规则是稳定约束，主要回答「怎么表达」。事实是否成立，交给来源和核查流程判断。

可以拆成几层：

  • 固定规则：禁用词、称谓、标点、引用格式、是否允许口语。
  • 风格样例：几段人工认可的优质表达，配上「为什么好」。
  • 结构偏好：是否先给结论、是否保留反例、是否使用表格。
  • 场景差异：不同对象和渠道对应不同密度和格式。

项目规则适合放在稳定的 system 指令、可缓存前缀或专门的 Style Agent 里。每次任务只取相关子集，避免规则挤占事实证据和产物本身的空间。

2.4 事实来源 ​

事实来源用于约束产物里可验证的判断。它和长期知识库有交集，但调度方式更严格。

事实核查时，Agent 需要看到：

  • 原始来源链接、文档标题、发布日期和访问日期。
  • 被引用的具体段落或数据字段。
  • 来源类型，例如官方文档、论文、产品公告、第三方报道。
  • 与当前论点的对应关系。

执行 Agent 可以看筛选后的事实摘要；核查 Agent 需要更接近原文的证据；交付前还要保留引用映射，方便人工复核。摘要帮助起草提速，原文片段帮助校验降低误读。

2.5 审稿反馈 ​

审稿反馈记录的是「这个产物如何演化」，不等同于项目规则或长期知识。

常见字段：

  • 反馈来源：用户、编辑、法务、专家审稿、合规检查。
  • 反馈对象：标题、论点、段落、事实、语气、结构。
  • 状态：待处理、已采纳、已拒绝、需要人工确认。
  • 处理理由：为什么这么改，为什么不改。

这类信息适合进入修订 Agent 和审稿 Agent。初稿 Agent 不一定需要看到全部审稿记录，否则可能过早收缩表达，写出只为规避批注的产物。审稿反馈要和项目规则、长期知识分开管理。

3. 调度进入不同 Agent ​

上下文调度器可以理解成多智能体系统里的「材料分发层」。它不替 Agent 做判断，而是在每次调用前回答四个问题：

  1. 这个 Agent 现在承担什么动作？
  2. 这个动作需要哪些资料、规则和状态？
  3. 哪些信息必须原文进入，哪些可以摘要进入？
  4. 输出结果应该写回哪里，是否触发后续 Agent？

一个项目可以按下面的方式分发：

Agent主要输入不应默认输入输出写回
Research Agent任务说明、目标对象、检索范围、可信来源规则完整项目手册、所有历史审稿记录候选资料、来源卡片、事实摘要
Planning Agent任务目标、对象、场景、资料摘要、结构偏好原始长文档全文结构、论点树、缺口清单
Execution Agent结构、精选证据、规则子集、当前交付要求未筛选资料库、全部反对意见初版产物、待核验声明
Fact-check Agent产物、引用映射、原始来源片段、事实规则风格样例、营销表达偏好事实问题、引用修正、风险标注
Style Agent产物、项目规则、禁用词、场景样例大量事实原文、未处理研究资料风格修改建议、改写版本
Review Agent最新产物、任务目标、审稿反馈、验收清单与本轮无关的历史产物问题清单、通过/退回原因

这张表背后的判断是职责隔离。Research Agent 可以读更宽资料，Execution Agent 只应拿到筛过的材料；Fact-check Agent 可以要求原始证据，但不需要模仿项目风格；Style Agent 可以重写表达，但不能改变事实判断。隔离越明确，排查「为什么写错」「为什么漏引用」「为什么风格跑偏」越容易。

4. 调度策略 ​

4.1 先分类，再检索 ​

调度器收到任务后，先做轻量分类：

  • 任务阶段：研究、规划、执行、改写、事实核查、审稿。
  • 产物类型：技术文档、产品说明、客户材料、社媒短文、内部方案。
  • 风险等级：是否涉及事实声明、法规、价格、竞品、医疗金融等高风险信息。
  • 资料需求：需要检索知识库、读取当前产物、调用网页搜索，还是只用用户给定材料。

分类决定检索范围。比如「改写语气」通常不需要重新查产品文档；「补充最新模型限制」则需要重新查官方文档，并把检索时间写入来源卡片。语气问题主要依赖风格约束，时效性事实需要可追溯来源。

4.2 给资料打标签 ​

进入知识库的资料至少要有几组标签：

  • source_type：official_doc、paper、interview、product_note、review_feedback。
  • scope：全局通用、项目通用、任务专用、产物专用。
  • freshness：发布日期、抓取日期、是否需要复查。
  • authority：一手资料、二手解读、内部判断、用户偏好。
  • agent_visibility：哪些 Agent 可见，哪些只能看到摘要。

这些标签影响检索和排序。事实核查时，一手资料优先；风格改写时，项目样例优先；做规划时，对象画像和任务目标优先。标签的价值在于让调度器按任务阶段控制可见范围。

4.3 压缩和原文并存 ​

压缩要保留原文追溯能力，同时为不同 Agent 准备不同视图：

  • Research Agent 读取原文，抽取要点和来源卡片。
  • Planning Agent 读取主题聚合后的摘要。
  • Execution Agent 读取少量关键证据和可引用句意。
  • Fact-check Agent 回到原文片段检查出处。
  • Review Agent 读取最新产物和变更摘要。

这样既能减少 Prompt 体积，也能保留追溯能力。产物里出现一个事实判断时，系统应该能回到「它来自哪个来源、由哪个 Agent 引入、哪一轮审稿确认过」。

4.4 分清同步任务和后台任务 ​

Agent 链路里，有些任务必须在当前调用前完成，有些可以异步处理。

同步任务包括：

  • 读取用户本轮指令和当前产物。
  • 检索当前 Agent 必需的资料。
  • 校验上下文是否超出预算。
  • 高风险事实进入产物前，要求来源可追溯。

后台任务包括：

  • 把长文档切块、向量化和索引。
  • 生成项目级摘要、术语表和人物/产品卡片。
  • 汇总审稿反馈，更新可复用规则。
  • 统计哪些资料经常被引用、哪些来源过期。

如果用户要求「根据刚上传的 80 页白皮书立即写结论」，调度器应该先阻塞研究阶段，等白皮书完成解析和索引后再起草。否则 Execution Agent 可能只读到文件名和零散片段，输出会偏向猜测。

5. 一个可落地的数据流 ​

工程实现里，可以把上下文调度拆成六步：

  1. 接收任务：保存用户指令、目标产物、阶段、权限和截止时间。
  2. 任务分类：判断当前需要 Research、Planning、Execution、Fact-check、Style 还是 Review。
  3. 上下文预算：为当前 Agent 分配 token 预算，固定规则、当前产物、检索资料和输出空间各占一部分。
  4. 检索与组装：按标签检索长期知识库，读取本次任务状态，选择项目规则子集，组装带来源的 Prompt。
  5. 生成与校验：Agent 输出结构化结果，例如产物、引用映射、问题清单或改写 diff。
  6. 写回状态：更新产物版本、来源卡片、审稿反馈和知识库待处理队列。

简化结构：

text
User Task
  -> Context Scheduler
    -> Task State
    -> Project Rules
    -> Knowledge Base
    -> Source Cards
    -> Review Log
  -> Selected Agent
  -> Structured Output
  -> Product / Sources / Feedback / Memory Updates

调度器质量可以用几类指标观察：

  • 命中率：Agent 是否拿到了完成任务所需的关键资料。
  • 引用可追溯率：产物事实是否能回到来源卡片。
  • 上下文浪费率：Prompt 中有多少内容没有被使用。
  • 返工率：审稿退回原因是否来自资料缺失、语气不一致或事实不可靠。
  • 延迟和成本：同一任务在不同调度策略下的 token 消耗和响应时间。

6. 小结 ​

上下文调度解决的是 Agent 系统里的资料流动问题。它把本次任务、长期知识库、项目规则、事实来源和审稿反馈拆开管理，再按 Agent 职责重新组装。

这套机制带来三个结果：

  1. Execution Agent 拿到足够完成当前步骤的精选上下文，减少长资料对执行的干扰。
  2. Fact-check Agent 能回到原始来源，降低把摘要误当事实的风险。
  3. Style 和 Review Agent 能处理表达与验收，不必参与资料检索的全部细节。

后续讨论 LangChain 和 LangGraph 时，可以把它们放回这个问题理解：Agent 系统需要一套能检索、压缩、隔离、写回和追踪上下文的 Agent 工作流。更长的 Prompt 可以缓解一部分窗口压力，但不能替代材料分发、证据追溯和状态写回。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构