不知道有没有比较好的项目 使用dify的agent 总不能把一堆agent给与用户选的用吧，佬们有没有什么好的实践
3 Likes
申请加入讨论，我们公司也是正在探索这方面。
我们打算：
- 找到一个开源的ChatUI，改吧改吧，用@来mention不同的Agent，类似Discord
- 直接包一层Chatflow，用Agent模式，其他的flow转为Tools让Chatflow中的Agent来调用
看看大佬们还有什么更好的解决方案？
很高的告诉你。没有
现在没有任何agent的方案是让我觉得有价值的 ！
如果有。 早就拿出来吹了！
单agent处理任务的token消耗是chat的4倍
多agent处理任务的token消耗是chat的15倍！
很多时候使用agent处理任务 往往价值消耗和回报是不对等的！！！
至少 ，我探索了很久。 还没找到比较好的应用场景！
workflow是现在，agent是未来
4 Likes
你这个还是对话，会话，这种形式，我的想法是嵌入原有的业务中去，做辅助
我和你的感受相同
1 Like
我们调研发现dify还是比较适合快速开发上线，如果业务复杂还是直接鲁代码比较合适，我们都是选择类似langgraph跟adk这种code框架，结合业务需求手鲁agent服务来用
关注 mark
前排围观
mark 关注一下，看看有没有大佬
有没有前端AI, 先生成一个框架,然后鼠标点击输入改变的内容,这样的, 后端其实curosr 或 Claude code 足够了,但是前端还没有能打的
看佬的野心了，最简单的是啥，最简单的就是在原本的业务流程中，找一个简单，重要，且无聊的业务流程，简单点就是一个表单提交。然后把这个接口搞成mcp的样子，整个chat的agent引导用户完成表单的提交。
那如果牛逼一些，需要在前端花功夫，类似于支小宝或者钉钉那样，把前端的卡片交互做起来。然后把一部分业务搬到chat中去，核心流程弹卡片确认，其他的都通过对话的方式。携程也有类似的技术方案貌似。
这是产品角度了，如果佬关心技术实现，那我建议是，简单点就直接dify、百炼、coze这种平台，如果不能接入就自己维护一个dify，但是一旦真的要做深的话，那建议spring-ai，搞起来，举个例子就是可以自己实现man in loop，这一点还是很重要的。
1 Like
langchian好重啊 =-=
佬，说的太对了
确实很重 0.0
langgraph，没用langchain，不过langgraph也挺复杂的，我研究了挺久才玩明白
dify还是不太适合复杂业务的，至少说没有写代码方便
确实没得写代码那么灵活
目前落地应该是最难的吧，只能chat、chat还是chat
langgraph这让我想起来去年研究KAG的时候了，欲仙欲死。。。
mark一下，学习学习新思想