agent 框架 的开发成本 很低了

要阅读 anthropic 和 menus 这些公司的文章，能学到很多东西

目前是发现问题的价值极高

agent 研发的壁垒在于 在一线 交互 研发 token 用户洞察 的 insights

上下文工程，开发的核心

一定要注意 cache 命中，降低 token 成本，减少延迟

在system prompt 中，不要把动态信息放入，例如，时间，环境这些随时会改变的信息

不同的模型的 follow instruction 的点也不一样，切换模型的成本并不低，但也没那么高。因为 SOTA 模型的能力基本上差异不大

agent 的开发流程，从 demo 开始

构建 demo 的时候，优先使用现有的框架，比如 langchian。因为他可以让你把一套架子快速搭建起来

构建 benchmark，针对使用场景构建自己是有的 benchmark。这个成本比较高。可以收集一些同样领域的开源 benchmark。

构建 baseline，把 agent 放到 benchmark 中，最少跑五遍，十遍，算出一个平均分，得到一个 baseline。因为模型的不确定性。千万不能只跑一遍就完事了。

这个 baseline 构建完成后，就可以作为你以后换模型还是调整 agent 的一个参考。（非常重要）

context

随着 context 增加，模型能力会下滑，注意力涣散。

上下文对内容的影响是很 treaky 的，渐进式披露很重要

错误记录要不要删除？

动态 prompt 注入机制（在执行间 注入到问题中，给他一套引导）

prompt 的扰动机制

压缩一定会产生幻觉，幻觉会在长任务中累积，最终失败

agent team VS sub agent

bitter lesson for agent （ 文章建议阅读）

agent 开发中

架构简介，不断调整核心策略，方便模型理解，就能吃到模型进步的红利

最核心的 react 结构-观察，思考，执行，观察

tools

tool 本身也是上下文，需要针对模型设计，命名要有逻辑

工具不要太多，早起的 mcp 很火，现在基本不怎么用了。原因是 mcp 太多。会导致cache 命中变低。性能会下滑。

tools 不会是未来，mcp 也不是，渐进式披露的 cli 才是未来。所以现在的 agent 的工具，都是 cli 操作。目前的 claude code，openclaw， hermes 都是如此。

memory

模型很难正确提取关键点

memory 如何存储，如何分层次存储，如何检索，如何读取，如何更新？

比如，真实场景下，很多记忆点是会变的。

另外，提取记忆点会花很多的算力。

还有，记忆的检索，rag 语义检索有很多难题。

目前最好的是，把 memory 和 query 丢给一个小模型去检索。这样是最准确的。