推文

@fireandstart · 2026-10-13 19:54

这条时间线把 RAG 的演进讲得很清楚：从固定检索，到让 Agent 决定何时检索，再到主动从文件、技能与记忆等来源组织上下文。对我来说，关键变化不是给 RAG 换个名字，而是把“提供什么信息、何时提供、如何控制成本”变成系统设计的一部分。实际落地时，我会先明确任务需要的上下文，再组合检索、工具和长期记忆；同时给来源、权限、时效性和 token 预算设边界，并记录哪些信息真正改变了结果。否则上下文越多，噪声、过期内容与成本也可能一起增长。评估时可以用固定任务集比较不同策略的成功率、延迟和 token 消耗，再看 Agent 是否能判断何时跳过检索、何时补充证据。这样才能知道所谓 context engineering 是否真的改善了决策，而不只是增加了更多资料和流程。

曝光 24 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 12.65613476193795