【上下文工程/Agent】上下文工程与 Agent 设计的新趋势：

腾讯云 Forge Memory 的实践总结：让 AI Agent 告别"新人第一天入职"。 1、一次任务形成的工程判断，有三个断点会消失这篇文章想要解决的核心问题：Agent 可以重新读懂代码，却很难从最终实现还原曾经比较过的方案、被排除的路径和选择成立的条件。第一次做了个需求，排查了各种可能找到根因——下一个类似任务来，新 Agent 还是得从头踩一遍坑。 作者提出了三个断点： 代码留下了结果但理由消失了、任务交付了但经验没进入下一次、知识保存了但没真正进入决策。长上下文研究有个叫"Lost in the Middle"的发现——相关信息在长输入中的位置会影响模型利用效果。所以不是塞越多越好，而是识别有价值的经验放到正确的任务里用。 2、四阶段演进：从日志到双向准入第一步先让经验留下来——写 Daily 日志低成本记录观察。但很快暴露出三个问题：事实和猜测混在一起无法区分、没有稳定身份导致分三次补充只能加三段文字、只能增长不能收敛。 第二步是架构转折：把知识变成带结构的独立对象，字段包括 ID（能修正同一对象）、适用范围（限制结论带到哪里）、证据记录（判断的来路）、状态（草稿/活跃/归档）和修正历史。 第三步是"双向准入"——写入侧有门槛（不是每次新发现都写），读取侧也有门槛（不是所有存的知识每个任务都该读）。 第四步拆职责三层：AI做语义判断、确定性执行层做机械动作、人处理高风险团队事实。 3、六种知识角色各司其职知识库不只是文档堆砌。Forge Memory 按用途分类六类： 1）导航知识回答"从哪里开始读"， 2）模型知识回答"这些代码共同表达什么"， 3）操作手册回答"这类任务通常怎样完成"， 4）诊断知识回答"出现异常后应该怎样找到原因"， 5）决策理由回答"当时为什么这样选"， 6）约束规则回答"当前哪些选择可以继续讨论"。 关键设计哲学是：知识只保留那些会影响判断但很难从代码直接读出来的信息。代码已经能答的内容交给代码，别重复。每条知识落地就是普通 Markdown，只是文件头保留了 id/type/scope/source 等机器可读字段，方便治理和检索。 4、两道门机制控制知识流动知识运行时（Knowledge Runtime）有两道门：读取准入决定长期层的哪些内容进入当前任务，沉淀准入决定当前任务的哪些结论改变长期知识。 读取门的设计：先过滤消费资格（未完成骨架不进推荐、停用知识退出消费、未经人工确认的约束不生效），再用任务已暴露的文件/模块/概念等事实信号缩小范围选出有限候选，只有与当前决策相关的才展开正文。 更精巧的是记忆子流程——知识读取发生在一个独立的子流程里，主 Agent 不需要理解知识的内部协议，只收到提炼后的"知识作用"。 沉淀门的设计：默认不写入。判断一个新经验是否有资格改变长期知识，五个问题依次问：未来还会不会遇到？有没有当前代码或任务结果作为证据？离开这次任务还能独立成立吗？是否足够完整？长期层里是否已存在同一个判断？结果是三选一：不沉淀 / 更新已有知识 / 新建知识。原则是"能不增加就不增加，能修正已有的就不再创建新版本"。 5、真实任务中的数据：70% 被读取，探索路径缩短一半约 70% 的任务中可以看到项目知识被实际读取并影响后续探索；近 30% 的任务明确判断无需产生新长期知识；40% 以上的任务形成已有知识的更新或新知识对象。反向复盘显示，有知识沉淀的情况下，Agent 的代码入口定位、调用关系梳理和历史方案确认可以缩短一半以上。更重要的是，知识没有让 Agent 更依赖历史结论——最终判…

我用豆包，给一群主播演示了什么叫 Agent。 今天这篇文章，是我前两天给朋友公司做分享之后整理出来的文字稿。 我朋友在石家庄经营一家直播电商公司，大概有 30 多人，团队基本上都是以主播和运营为主。他邀请我过去，给大家聊聊团队到底应该怎么开始使用 AI。 说实话，我其实不太擅长公开表达。平时更多是写东西，或者和朋友聊天。 但这次分享结束之后，参与的同学反馈还不错，也让我觉得这件事可能对很多团队都有参考价值。 所以我鼓起勇气把这次分享的内容整理出来，和大家分享一下。 朋友公司的员工，在此之前其实基本没有接触过 Agent 工具。大家日常最熟悉的 AI 产品就是豆包，所以这次分享我也直接从豆包开始讲起。 毕竟现在豆包不管是电脑端和手机端都可以使用办公 Agent，手机端可随时查看任务进展、补充指令，大家不需要额外安装任何独立的电脑端软件。 本来就在用豆包的直接就能开启功能，门槛最低、体验最轻，也不会因为多装一堆工具搞得电脑卡顿、占内存，就可以开启办公 Agent 模式。