Vibe 日记（11）｜Agent 开发记录
背景
近期在做 #MopanAgent，包括最近询问大家的什么是 #skill 梳理出了一些我对 Agent 开发的理解，当然这两篇文章已经足够好了：
好用的 Agent == 懂
开发一个“好用”的 Agent ~= 你非常懂你开发的 Agent 要干的活儿。在有了诸多 Agent 开源库、Agent SDK 之后，其实大家所说的好不好用我的感受是：
- Agent 做出来 ~= 0 成本
- Agent 好用的 90% 情况 → 依赖的是模型好
- Agent 特别好用的最后 10% → 依赖你懂不懂
比如，要做一个游戏 Agent == 你很懂游戏创作中要做什么、怎么合作、怎么验收 bla bla ...
那些“混乱“的概念
- #prompts 最原子化的使用 LLM 的定义，可以被用在定义每个 Agent 的 System Prompt，也可以是 Workflow 中某一个 step 的 Prompt
- #workflows 其实就是你特别懂的一个确定的流程（类似工作里当下最佳实践的小 SOP），就算不定义 workflows 用 agent 一轮一轮干活儿也能做出来，但是就是费钱又慢
- #skills 一些“最佳实践”的文字总结，有点像公司里有一些人写的很好地文档，你不看它也能干活儿，看了它可能干的更好一点。其实 #skills 和 #workflows 都是某种最佳实践的沉淀，只是一个更自然语言一些，一个更具体到干活儿 SOP
- #tools 一些内部 API 调用，比如怎么生成一个素材，怎么搜索一个 xxx 确定的功能
- #runtime 就是事情怎么跑起来，通用 Agent 的 runtime 就是个电脑，具体场景可能是个服务或者其他东西
怎么优化？从做出来到好用
做出来 → 做的好，这条路非常难，有几种路径：
- 0→1 开发，就是团队里必须有很懂这个场景的人，在什么反馈都没有的情况下手搓出一个基本能用的版本。
- 建设 eval 机制，要有 bench 或者是 eval 标准，标准的定的好不好，同样依赖团队里（或者是核心 partners）可以建设好。然后通过 eval 不停地调 agent 结果（这个和调 model 其实也差不多了）
- 用户的真实使用反馈+数据，Agent 用户越多就越能发现某个环节不够好需要优化，如果很幸运的增长起来数据就更值钱了。数据少可以用来分析优化 eval 和 agent，数据多就接近可以 "post train" 了