大家好,我是为什么叫QQ
Resell最近发布了一个全新的开源Agent框架
EVE
官方给它的定位极其嚣张
Agent领域的NextDNJs
你可能会想现在市面上的Agent
框架没有100也有80个了
从Line Chain到AutoGen
从MetaGPT到CrewAI
Resell凭什么敢喊出这种口号
难道又是一个套壳的玩具
但当我仔细扒了它的原码和架构设计后
我发现事情没那么简单
这个框架可能会彻底改变我们写Agent的姿势
如果你在过去一年里写过Agent
你一定体会过那种被手搓基建支配的恐惧
写一个demo很简单
调个API写断
Prompt跑个Python脚本
一个简单的Agent就跑起来了
但推到生产环境就不一样了
你需要自己做持久化
Agent可能会运行好几天
中间网络断了怎么办
Agent状态丢了吗
对话历史没了吗
你得自己处理这些
然后是沙香隔离
AI生成的代码不能直接跑在业务服务器上
万一Agent写了个RM
RF
这样的命令怎么办
谁负责
还要自己接Slack
接丁丁
接企业内部系统
甚至还要自己写一套审批流
防止Agent的自作主张
把生产数据库给删了
这些脏活累活
跟Agent的核心业务逻辑
半毛钱关系都没有
但你需要花80%的时间去搞定它们
这合理吗
其实现在的Agent开发
就特别像当年
没有Next.js时的Web开发
大家都在疯狂地重复造轮子
拼凑各种路由 打包工具和状态管理
每个团队都在写自己的一套脚手架
Rissel这次搞出Eve的思路非常明确
不要让开发者再去拼凑零件了
我把生产环境需要的所有基建
直接打包送给你
而且它用了一个极其讨巧的设计理念
文件系统优先
File System First
就像Next.js把目录变成了路由一样
Eve把目录变成了Agent
接下来我们从工程落地的视角
硬核拆解一下Eve到底解决了哪些痛点
文件系统及Agent
在Eve里你不需要写一堆复杂的注册代码
一个目录就是一个Agent
你的Agent.ts用来配模型
Instructions.md就是系统提示词
你想加个工具
直接在Tools目录下建个TypeScript文件
文件名就是工具名
Eve会在构建时自动发现它
比如你建一个Tools.run下滑线SQL.ts的文件
里面有Zo的定义输入Schema
Eve就会自动把这个工具暴露给模型
模型可以直接调用RunSQL
不需要任何额外的注册步骤
你想教它个新技能
在Skills目录下
Deal个Markdown
模型在需要的时候会自动加载
比如你有个Skills
Revenue
Definitions
.md
里面写着收入是扣除退款后的金额
按周统计周一为起点
这样的业务规则
当用户问上周收入多少时
模型会自动加载这个技能
确保回答符合公司的定义
这种设计太直觉了
你一眼扫过去就能知道这个agent是干嘛的
能用什么工具
有什么技能
它消除了传统框架里那种到处注册
到处引用的意大利面条代码
这极大的降低了团队协作时的认知负担
新人上手也快得多
你不需要学习一堆复杂的API
只需要理解目录结构就行了
开箱即用的生产机基建
这才是EV最核心的杀手键
它底层集成了Workflow SDK
这意味着什么
意味着你的agent是自带持久化执行的
每一步操作都会被checkpoint记录下来
EV把绘画做成checkpointed workflow
已完成的步骤会记录结果
不会重跑
崩溃或部署后
可以从已确认的步骤继续
遇到人工审批或等待后续消息时
Session可以暂停不消耗计算资源
这解决了一个agent的开发中最头疼的问题
状态管理想象一个场景
你的agent在处理一个复杂的数据分析任务
它需要先从数据库查询数据
然后调用一个外部API做分析
最后生成报告
在传统框架里
如果在第二部API调用时网络断了
整个任务就得重新开始
在EV里已完成的第一步会被记录
网络恢复后直接从第二部继续
但这里有个重要细节
如果某个Tool在执行中被打断
这一步可能会重跑
所以调用外部系统时
你要么做好密等设计
要么加上人工审批
这样才能保证数据一致性
安全问题他也想好了
这里要注意一个细节
EV把agent的生成和执行的代码
放进独立sandbox
包括shell命令脚本和文件读写
但开发者定义的tools
运行在应用run time中
可以通过ctx.getsandbox
调用沙箱
所以安全边界不是绝对的隔离
而是靠窄工具设计
权限控制审批和密等设计一起完成的
EV支持多个sandbox后端
在生产环境用versail sandbox
本地开发可以用darker micro sandbox
或纯bash
这样的分层设计
让你既能灵活调用业务系统
又能隔离AI生成的不可信代码
极简的human indial loop和多渠道分发
在EV的工具定义里
加个人工审批简直不要太简单
只要加一行needs approval判断
比如发现SQL查询超过50G
Bagent就会自动停下来
等你点个头它才继续
这解决了企业对agent行为失控的终极恐惧
当agent要执行一个会扫描
超过50GB数据的查询时
系统会自动暂停等待人工审批
这种细利度的控制是传统框架很难做到的
同一个agent的代码库
加个slack.ts就能接入slack
加个discord.ts就能接discord
核心逻辑完全不用改
这才是真正意义上的write once run anywhere
定时任务则放在schedules下
用chrome表达式触发同一个agent
你可以用同一个agent处理多个平台的请求
比如你的数据分析agent
可以在slack里回答问题
也可以通过API被其他系统调用
还可以通过定时任务每周生成报告
所有这些都用同一份代码
但这里有个很离谱的地方
很多人觉得用这种高度封装的框架
会失去对底层逻辑的控制力
觉得它太重了
其实你理解错了
EVE的重是重在
他帮你兜底了那些最容易出bug的基建层
他把脏活包揽了
反而释放了你的精力
让你能真正去思考
这个agent到底该怎么解决也有问题
在过去的框架里
你花大量时间在写连接器
写重视逻辑
写状态机
而在EVE里
你只需要关心两件事
你要给agent什么指令
你要给他什么工具
而且EVE并不是一个黑盒
它是完全开源的
基于APACHE 2.0许可证
你可以看到所有的原代码
可以自定义任何部分
如果你需要特殊的sandbox后端
你可以写自己的适配器
如果你需要特殊的渠道集成
你可以用Define Channel自己写
所以EVE不是限制你的自由
而是给你一个坚实的基础
让你可以在上面自由地构建
所以EVE给我们带来了一个非常重要的认知升级
agent不再是一段脚本
而是一个系统工程
一个真正能落地的企业级agent
它的核心竞争力不在于你用了多牛的prompt
而在于你有没有一套稳定
安全可追溯的工程脚手架
EVE其实是在用工程化的手段
却对抗大模型本身的不确定性
它把大模型包装成了一个可靠的工程组件
这才是它自称agent领域的nextdngs的底气
让我给你举个具体的例子
假设你要为一个电商公司构建一个客服agent
这个agent需要查询订单信息处理退货申请
在slack和webchat两个渠道同时运行
每天生成一份客服报告
用传统框架你需要自己
写数据库连接和查询逻辑
自己实现状态管理确保退货申请不会丢失
自己写两个渠道的适配器
自己实现定时任务和报告生成
自己处理错误恢复和日志追踪
这可能需要几周的开发时间
用eve你只需要在tools query
orderts里写个查询函数
在tools process下划线refund
ts里加个nextapproval标记
在channels目录下加两个文件
在schedule s目录下加个定时任务
整个过程可能只需要几天
而且意味会自动处理持久化
错误恢复日志追踪等所有的基建工作
Rissell内部的应用实践
Rissell公开提到
他们在生产环境运行100多个基于eve的agent
其中包括D0数据分析agent
每月处理3万多个分析问题
还有销售线索agentathena销售cockpit
Vertex支持agent
Draft0内容agent和Vluoagent等
这些都是真实的生产级应用
说明eve的持久化执行sandbox隔离
Human in the loop和多渠道能力已经经过验证
这些agent的共同特点是
他们都需要处理长期运行的任务
调用多个外部系统在关键操作前获得人工确认
这正是eve设计的核心场景
未来随着模型能力的提升
agent的业务逻辑会越来越复杂
多agent的编排会成为常态
一个主agent带着一群子agent的干活
eve这种约定优于配置自带基建的模式
给出了一个很有参考价值的方向
需要说明的是
eve当前仍处于public preview阶段
官方文档明确说
API文档和行为在GA前可能会变化
但这不妨碍它成为一个有影响力的设计参考
Rissel把agent的工程化问题收敛到文件系统
Workflow Sandbox Channel和Evos这几个约定里
这个思路本身就很值得借鉴
eve的开源属性
意味着社区会不断贡献新的工具
新的技能
新的集成
随着更多团队的时间和反馈
这个框架会不断完善
最后让我分享一些eve的最佳实践
写好你的instructions
instructions
md是agent的大脑
好的instructions应该清晰具体有约束
不要写你是一个有帮助的助手这样的废话
要写你是一个数据分析师
你的工作是回答关于公司数据的问题
优先使用精确的数字
而不是估计
如果你不能从数据中得出答案
就直说
精心设计你的tools
每个tool应该做一件事并且做好
不要设计一个超级tool
什么都能做
而且tool的输入输出要清晰
用zod定义scammer
让模型知道怎么调用
用skills来教导agent
skills是markdown文件
用来教导agent的如何做事
比如你可以写一个
skillshowto
-write-good-sequel-md
里面写着
写sql时要避免n加1查询这样的建议
当agent需要写sql时
他会自动加载这个skill
充分利用human in the loop
不要让agent的完全自主
对于重要的操作加上审批流
这不仅提高了安全性
也提高了用户的信任度
监控和追踪
eve生成的open telemetry追踪非常详细
充分利用这些信息
来理解agent的行为
定期审查追踪日志
找出agent的问题所在
总结一下
别再手搓玩具agent了
eve把企业机基建
直接塞进了文件系统
如果你也收购了
天天修agent的底层bug
真的建议去试一下eve
那么你目前在开发agent的时
遇到最头疼的工程化问题是什么
把你的看法打在公屏上
或者在评论区告诉我
我是为什么叫QQ
我们下期见
别忘了长按点赞
一键三连