我尝试在智能体平台上构建了六个月。以下是我迁移到自托管技术栈的原因。
摘要
一位开发者分享了他们在六个月后从智能体平台迁移到自托管技术栈的经验,指出了对模型选择、成本和执行隔离的更好控制,导致 Token 成本下降了 60%。
我在一个智能体平台上构建了六个月。它具备内存、工具调用、技能市场,看起来功能齐全。但它并不符合我的需求。该平台提供了脚手架,包括身份验证和部署。然而,它无法处理按任务选择模型、执行前的计划审查,以及与生产基础设施的隔离。当智能体选择了一个高级模型进行代码检查时,我无法了解原因。当它触及一个暂存数据库时,我无法将执行过程沙箱化。该平台恰恰抽象掉了那些我需要精确管理的复杂性。我用显式的模型路由、按任务计费和执行前的审查门禁重构了相同的工作流。Token 成本下降了约 60%。设置过程更困难,因为有更多可调参数,但这种控制是值得的。并非所有人都需要这样做。已有基础设施的团队可能更倾向于托管路径。
相似文章
将我们的智能体栈从 Dify 切换到 OpenAgent,以下是做出这一决定的原因。
一位开发者解释了为什么他们的团队从 Dify 和 Langflow 转向 OpenAgent 用于生产级智能体工作流,并强调了 OpenAgent 更简洁的架构、直接的 REST/SSE 端点、内置的提示版本控制以及原生 Atlas Cloud 集成。
"在什么情况下添加另一个代理实际上会损害您的系统?问这个是因为我的6代理流水线比旧的2代理流水线更慢且更不可靠"
一位开发者分享了使用AI编排框架(LangGraph, CrewAI, AutoGen)的真实体验,指出了原型设计便捷性与生产可靠性之间的权衡,并向社区询问如何处理失败、人机协同和Token成本问题。
子代理在长代理运行中占据大部分Token成本:实际可将使用量降低70%至90%的修复方法
本文分析了 Bai 等人 2026 年的论文,该论文表明,子代理和上下文膨胀导致长代理运行中的Token成本比普通聊天高出约1000倍,并提出了三种实用的修复方法(PLAN.md、读取预算、带外备注),可将Token使用量减少70-90%。
经过数月的智能体构建,我改变了关于什么最重要的看法。
作者反思了将AI智能体从原型推向生产环境的挑战,得出结论:可靠的编排和安全保护机制比模型的渐进改进更为关键。
长期运行 AI 智能体最经济实惠的方案
一位开发者讨论了以成本效益高的方式长期运行用于金融市场分析的 AI 智能体的策略,并分享了使用 Claude 和 Gemini API 的经验。