用 claude code 做 ai agent 是更好么

我是用 claude agent sdk 做的。有一个不好，它不支持 openai 的格式，不过问题不大，国内模型基本都有 anthropic 的兼容接口，不用自己实现 plan ，skills 等，我做了一个跨境对平台产品构建与报价系统 挺好用

你不用从零开始，如果你没什么基础，那么它能直接变成一个可用度很高的 Agent 。但是它的可定制性受限于本身的能力限制，要看你是否对它需求更多。Skills 出现之前这个短板很明显，发布这个功能之后，在更加具体的应用场景上要更好用很多

个人经验，自用或者用户量小怎么顺手怎么来，能 run 就行，大规模上生产还是得手搓，手搓最大优点是流程可控和省成本，否则 token 账单能让你哭死

@TimePPT 但手搓，就意味着你要对整个系统构建至少有一个完整概念，学的东西不少。不过也不是啥大事。现在所有这些框架/sdk 无非就是全人工 pattern<-->全 AI 决策之间找一个平衡，做多做少的问题

claude 指令跟随比较好，function calling 效果好，mcp 的原研厂啊

我就是这么做的，基于 Claude SDK 封装了一个 Task Engine ，不同的子 Task 共享同一个工作区。

@TabGre 问问你是接入的哪家的？如果商用的话 用 glm 4.6 那个套餐咋样？

正在做这方面尝试，现在国内的各个模型厂也全都是便宜大碗适配 cc ，成本可控

别老是听别人说接收二手信息，看官方文档，自己撸体验一下

看好 codex ，开源，想咋改咋改

从有 chatgpt 开始,我尝试过两次手搓 bi agent, 就运营随便提个统计需求, 能让开发写半天最后得到一个超复杂 cte 表达式的那种. 都因为上下文不够长, 或者工具调用出错, 最后只能得到一个半成品 sql, 开发最后还是得在那上面改一些才能用.

直到 cc 的 agent, 拆解需求, 看表结构, 制定执行计划, 工具交互, 出错了就改, 甚至重新制定执行计划, 50 多轮交互, 完美解决. 真和人类工程师一样, 把大问题拆小, 逐个解决, 有问题就改. 最后合并成解决方案. 反正我用 dify 或者 langchain 都搓不出这么厉害的 agent.

上下文压缩到极致, 系统提示词里只要有表名和描述, 它自己会去做 desc, 表结构里外键把要用到的表字段描述的很清楚, 体验下来效果极佳. 搓出来那一刻庆幸自己不是搞 bi 的, 不然几乎当场失业.