Vibe 日记（11）｜Agent 开发记录

背景

近期在做 #MopanAgent，包括最近询问大家的什么是 #skill 梳理出了一些我对 Agent 开发的理解，当然这两篇文章已经足够好了：

• Anthropic: Building effective agents
• OpenAI: A practical guide to building agents

好用的 Agent == 懂

开发一个“好用”的 Agent ~= 你非常懂你开发的 Agent 要干的活儿。在有了诸多 Agent 开源库、Agent SDK 之后，其实大家所说的好不好用我的感受是：

• Agent 做出来 ~= 0 成本
• Agent 好用的 90% 情况 → 依赖的是模型好
• Agent 特别好用的最后 10% → 依赖你懂不懂

比如，要做一个游戏 Agent == 你很懂游戏创作中要做什么、怎么合作、怎么验收 bla bla ...

那些“混乱“的概念

1. #prompts 最原子化的使用 LLM 的定义，可以被用在定义每个 Agent 的 System Prompt，也可以是 Workflow 中某一个 step 的 Prompt
2. #workflows 其实就是你特别懂的一个确定的流程（类似工作里当下最佳实践的小 SOP），就算不定义 workflows 用 agent 一轮一轮干活儿也能做出来，但是就是费钱又慢
3. #skills 一些“最佳实践”的文字总结，有点像公司里有一些人写的很好地文档，你不看它也能干活儿，看了它可能干的更好一点。其实 #skills 和 #workflows 都是某种最佳实践的沉淀，只是一个更自然语言一些，一个更具体到干活儿 SOP
4. #tools 一些内部 API 调用，比如怎么生成一个素材，怎么搜索一个 xxx 确定的功能
5. #runtime 就是事情怎么跑起来，通用 Agent 的 runtime 就是个电脑，具体场景可能是个服务或者其他东西

怎么优化？从做出来到好用

做出来 → 做的好，这条路非常难，有几种路径：

1. 0→1 开发，就是团队里必须有很懂这个场景的人，在什么反馈都没有的情况下手搓出一个基本能用的版本。
2. 建设 eval 机制，要有 bench 或者是 eval 标准，标准的定的好不好，同样依赖团队里（或者是核心 partners）可以建设好。然后通过 eval 不停地调 agent 结果（这个和调 model 其实也差不多了）
3. 用户的真实使用反馈+数据，Agent 用户越多就越能发现某个环节不够好需要优化，如果很幸运的增长起来数据就更值钱了。数据少可以用来分析优化 eval 和 agent，数据多就接近可以 "post train" 了

因此 Agent 未来会有2个预测

1. 最重要的场景、即数据最多的场景一定会反向训到模型里，那些所谓的 #skill、#workflow 价值会下降

2. 所有大场景，如果交互足够简单（就是文字、代码、tooluse、computeruse ...），通用 Agent 都会想办法实现，垂直 agent 真的就要很垂直，否则没啥活路