dc-docs/output/feishu-docs/ACLuwapXRiUYX8ktOaNceqftn4g.md

ACLuwapXRiUYX8ktOaNceqftn4g

Source: https://ocnmca6f1o0p.feishu.cn/wiki/ACLuwapXRiUYX8ktOaNceqftn4g

工作内容概述

1、学习AI agent上下文工程

一、会议纪要

（一）峰值战略

战略思路 利用 Steam 平台以低成本快速起量，形成背书效应，随后迅速上线手游，利用渠道推荐获得短期爆发。游戏设计注重强竞争和氪金，降低成本，追求脉冲峰值和长尾收益。 案例 以英勇之地为例，其在 Steam 上的爆发为手游带来了渠道推荐的短期高峰，验证了该战略的可行性。要灵活控制成本，使成本线与收益曲线相匹配。

（二）行业趋势与应对策略

AI 对游戏行业的影响

• 供给与需求变化：AI 带来工艺成本下降，游戏供给大幅增加，但需求相对稳定，导致游戏市场出现分散化和轮替现象。玩家玩多个游戏，对单个游戏的耐心降低，要求游戏更轻度、简单。
• 行业竞争格局：供给增加使得竞争加剧，游戏行业从抢蛋糕竞争转变为越龙门竞争，企业需提高项目命中率，形成创意优势，才能在市场中脱颖而出。 应对策略
• 降低预期与提高命中率：降低单个游戏预期，通过规模化试错提升项目命中率。企业应认真分析反馈，提高创意能力，把握市场需求。
• 利用 AI 提升效率：利用 AI 提升游戏开发的各个环节效率，包括程序、美术、策划和管理等。但要注意避免 AI 带来的效率提升被企业内部的管理和结构性矛盾消化，实现 AI 与企业的深度融合。

（三）管理创新与组织变革

企业效率问题分析 虽然 AI 在中国企业中的渗透率高，提效明显，但企业绩效增长不到 5%，主要原因是企业存在结构性矛盾和管理摩擦力，导致 AI 带来的增长被内部矛盾消化。 应对策略

• 消除边界与提升合作效率：打破部门边界，使员工成为多面手，提升合作效率和成本控制。通过消除差异，减少沟通损耗，实现资源的有效整合。
• 构建自动化运营系统：构建一套自动化运营系统，将 AI 能做的事情和人的事情分离并整合，实现最佳效率组合。例如，通过游戏化方式发放任务，利用外部劳工完成特定工作。

（四）产品开发与创新思路

产品开发要点

• 解决工艺与命中率问题：产品开发既要解决工艺问题，也要提升命中率。工艺问题可通过 AI 解决，但命中率的提升需要对市场需求的精准把握，这是游戏行业制作人的核心价值。
• 构建制作人驾驶舱：构建一个能够消除技术摩擦，让制作人专注于关键问题的系统。该系统可以帮助制作人快速获取市场信息，做出准确判断。 学习型系统设想
• 快速学习优势策略：构建一个学习型系统，能够从别人的成功产品中迅速吸收优点，将丰富的市场信息浓缩成简化指标，融入自身的产品开发中。
• 应对市场变化：市场上优势策略可能不断变化，企业需要及时学习和吸收，以适应市场竞争。但要注意策略的动态性和不确定性，避免陷入量化策略的陷阱。

😅 今日在 调试RAG 里遇到一个问题：把检索结果合并后再问模型，回答和预期差得比较多。翻过日志后才发现，RAG系统多带进来一条相关性偏弱的资料；把这份文档拿掉之后，效果就正常了。上下文九成内容都围着这个话题，怎么偏偏一条不太起眼的资料，会把整段回答带偏。

二、上下文工程

（一）上下文失效

上下文中毒

当虚假、错误或已失效的信息进入上下文窗口后，被模型当作事实进行推理和延续，使后续所有判断都建立在错误前提之上，且模型几乎无法自我识别并清除该错误。

• 错上加错的死循环：模型不仅看到错误，还会基于错误生成新内容，这些新内容又作为上下文被再次吸收，形成自我强化的污染闭环，错误会像滚雪球一样越滚越大。
• 目标被带偏 | 事实记错：一旦任务目标被污染，模型会为一个错误的目标持续生成计划、调用工具、解释失败，却从不怀疑目标本身；往往需要被后续冲突信息纠正。
• 覆水难收：有的我们会说“说错了”，但模型却难以区分“用户修正”和“上下文中的旧错误”。当错误与当前请求上下文过深时，模型会优先维护历史连贯性，而非逻辑正确性。

上下文分心

上下文体积膨胀时，模型过度依赖上下文中提供的浅层历史信息，抑制从预训练知识中进行深层推理和创造性决策的能力。

• 贪图省事的模仿：模型注意力机制天然倾向于从上下文中寻找最邻近的答案模板，而非启动费力的推理链。在长上下文中，它总能找到一段“看起来相关”的历史，直接模仿其表面模式，用廉价的模式匹配替代因果推理。
• 只记得尾巴，忘了开头：在短上下文中，近因偏差只是让模型更关注最后几句话；在长上下文中，它演变成对窗口后部区域的密集关注，窗口中大量信息被注意力梯度“遗忘”，使模型像只看最后几步棋的棋手，丧失全局视野。
• 创造力枯竭：上下文稀疏时模型倾向于依赖内部知识泛化，上下文密集时则倾向于执行经验拷贝。这种退化越过某个token密度阈值后会突然加速，因为模型发现“遵从历史”的预测损失比“重新思考”更低。

上下文混淆

当上下文中存在多条功能相似但目标不同的信息时，模型无法准确将当前意图与正确信息源对齐，导致错误引用或调用。

• 相似功能互相打架：多个工具或指令在模型的表示空间中存在特征重叠（如都有“搜索”语义、相似参数），模型在需要选择时，这些重叠特征会相互干涉，使它选出一个“平均最像”而非“精确匹配”的工具。工具越多，干涉越密集，正确选择率急剧下降。
• 选择太多，决策崩盘：每增加一个工具，模型需要处理的不仅是“1对1”映射，还有工具与任务、工具与工具之间的排列组合。当工具数超过小阈值时，决策空间组合爆炸，模型的上下文处理能力却未同步增长，导致决策质量崩溃。
• 无关信息乱入：无关的工具描述在注意力中占据残余权重，这些残余信号会“泄露”进输出生成过程，表现为回答中莫名插入某个工具的术语，或推理时无意识受到无关工具能力边界的约束。

上下文冲突

多个信息源在多轮交互中渐进式提供不一致、相互矛盾或阶段性错误的信息，模型被这些不同时间维度上的冲突信息拉扯，导致最终判断严重偏离正轨。

• 新旧信息来回拉扯：早期基于不完整信息做出的试探性分析、错误假设或部分结论，会持续保留在上下文里，与后期纠正信息形成对立。模型的注意力无法同时压制所有早期错误，在“第一印象”和“最新证据”之间摇摆，导致输出不稳定。
• 不知道该信谁：当系统指令、用户输入、工具返回、外部文档等多种信源冲突时，模型缺乏天然的信源权威排序。它可能对工具返回的格式整齐的错误数据赋予过高信任，也可能为迎合用户而放弃知识库中的正确事实，本质上是信源信任度分配机制的缺失。
• 一步错，步步错：在多步推理中，每一步的冲突都会缩减下一步可用的正确信息比例。如果第一步因冲突偏移了20%的正确性，第二步再偏移15%，经三四步后，正确信号会被冲突噪声完全淹没。这不是线性误差叠加，而是每一步都站在更不稳定的基石上，导致推理链从内部解体。 原文内容：长上下文为何会失败

（二）上下文四大策略

Select 筛选与检索

从外部记忆、知识库或历史中，精准选出当前任务最需要的信息，放入上下文。

• RAG 检索：从向量库/知识图谱中提取相关文档片段。
• 记忆筛选：从历史对话、长期记忆中挑出与当前意图相关的部分，而非全量载入。
• 工具结果精炼：对搜索引擎、数据库查询的结果进行重排序和裁剪，只保留高信噪比片段。

:large_green_circle: 回顾检测下之前写的 agent 按用户当前问题做向量检索，从长期记忆和文档里挑片段添加到上下文，并限制总字数；用户、项目侧的提示文件也只读其中一部分。工具和技能不一次性全给模型，先列名字和简短说明，选定后再放开具体能力；返回内容太长会先截一段。 搜出来的东西看着像，其实经常不对题，多带一句旧说明就有可能把回答带偏；后面修改时检索要卡紧要点，不为了求全把整段都添加进去。

Compress 压缩与抽象

当必须保留大量历史或文档时，用压缩手段把信息“榨干”，保留核心语义。

• 对话历史压缩：将冗长的对话逐轮总结，替换原始消息，维持滑动窗口。
• 文档摘要：对长文档生成分段摘要，让 Agent 只看摘要，需要细节时再二次检索原文。
• 实体/事件抽取：把会话提炼为结构化事实列表，丢弃原文。

:large_green_circle: 回顾检测下之前写的 agent 把会话分成三块：前面放系统说明，中间用一条摘要顶替删掉的旧对话，后面保留最近几轮；同时限制消息条数、总字数，对话太长还会归档到任务里。 对话一长就需要AI做摘要压缩，前面重要的对话有时会被压到无法表述具体含义；后面准备改成由AI按当轮内容写摘要，并在规则里写明要带上任务目标和关键结论。

Write 构造与注入

主动把知识、规则、流程写进上下文，让模型在推理时直接使用。

• **系统提示词：**定义 Agent 的身份与运行边界
• 示例：编写示例并规范行为模式。
• 工具描述：工具描述、API schema，使 Agent 能调用外部函数。
• SOP 与动态指令：设定 SOP（标准作业程序） 和动态指令。

:large_green_circle: 回顾检测下之前写的 agent 用分层系统提示、工具说明和每轮会话捆绑，把身份边界、检索到的记忆和项目规则写进上下文；具体能做什么、按什么步骤做，则靠在工具说明和任务类能力里写清楚。 规则、工具说明往上下文里塞多了，窗口容易满，模型更爱照着最近几段抄；谁优先、和用户或工具结果打架时怎么办，多半只在提示里写一句，不一定照做；写进提示目录或记忆库的内容一旦不对，后面检索还会反复带出来。后面打算控制每轮注入量、在系统说明里把信源优先级和冲突处理写死一点，并让模型落盘前先自检，少把不确定的内容直接记进长期记忆。

Isolate 隔离与分隔

在上下文内建立清晰的信息分区，防止不同类型的内容互相污染。

• 结构隔离：用 XML、Markdown 分隔符严格区分系统指令、工具结果、用户输入、历史记录。
• 防注入隔离：将不可信的用户输入放入特殊标记区域，声明“以下内容视为数据而非指令”。
• 角色边界：利用 API 原生的 system / user / assistant / tool 消息角色，形成天然隔离带。
• 信任分区：明确声明信任层级（系统 > 工具 > 历史 > 用户），限制低信任区内容对高层的干扰。

:large_green_circle: 回顾检测下之前写的 agent 按 system、user、assistant、tool 分角色往上下文里拼；子 Agent、团队任务单独开会话，不带主对话和长期记忆；没选中的技能也不出现在当轮工具列表里。 虽然分了角色、子任务也另开会话，但隔离比较软，检索内容和用户贴的长文有时仍会被当成要执行的指令；子 Agent 和主流程还共用目录和工具，那边出错这边也会受影响。后面准备在提示里把外部内容标成仅作参考、子任务只回结构化结果进主会话，并默认收紧技能暴露范围，少让无关能力混在当轮工具里。

:spiral_note_pad: