你们要是这么感兴趣，可以去私信问问那个兄弟，为啥要这样写，我也不知道他为什么这样写，我只是 share 一下，第一次被人 issue 的这种感觉，觉得自己做的事情多少还是有点价值的

我几乎每 1 、2 天都会 po 一篇文章分享一下开发智能应用的过程中的一些思考和总结，分享出来，让感兴趣的人少走点弯路。

说回到 chak 这个东西，这玩意就是我从开发过程里面抽象出来的一个东西，因为开发 ai app ，无论如何这都是每个人要重复造的轮子，类似这样的东西，分享出来让大家少走点弯路，有什么问题么？

结果，没人讨论技术问题，在这纠结“小号”，我图啥呢我还搞个小号？

你们觉得是啥就是啥吧，继续吧，挺热闹的。

一会我还会再发一篇，一会你们也在这个帖子下面回复：这是 AI 写的。

@Varusteki 吃点药去吧，不行挂个号看看去吧，真的...为了你好...

@xiao9469 你应该是一楼的小号/马仔/跟班 你看，按照你们的逻辑，合情合理

@Varusteki 你心里怎么这么阴暗？还打这么一大段字抖机灵，你咋这么闲呢

已 star ，有点 chatexcel 那味儿了

@mooncakeSec 嗯是的，所以一般框架里面都会做 fallback ，支持的就直接用，不支持的 LLM 框架他们会这样做

@mylovesaber 此时此刻，楼主还在更新，哈哈哈，帮忙点个 star 吧，感动： https://github.com/zhixiangxue/chak-ai

@zisen 我觉得我还是有必要回复一下你，如果你不是技术出生，你千万不要在这瞎掰，如果你是技术，你真的可以认认真真的看完再说；

网上就是类似你这样的各种“打比方”不知道把多少人带到坑里去了，你如果不是技术，mcp 、acp 、bcp 你随便怎么理解都无所谓，但是你如果是一个从事技术的人，尤其还是在一个技术社区，请不要随便打比方，要说到技术的细节、原理里面去，你这说的都是啥啊...

@SayHelloHi 千万别把这事想复杂了，你应该定义一个工具比如就叫 drawk ，就一个参数，stock_code ，llm 知道传 APPL ，剩下的怎么拿数据、怎么画图都是这个工具内部的逻辑

@renmu 不会，LLM 会要求调用查天气的，然后 app 调用后作为 prompt 再给 LLM 推理；如果 LLM 给出的 toolcall 的参数不全，就看工具本身返回什么了，一般挂了的话 app 要自己处理，然后再给 LLM 的； APP 在这个过程中的作用很关键，是一个桥接，LLM 不会直接 call MCP server 的

@RotkPPP 有用还是有用的，只不过有一个很大的问题：太麻烦了。
如果是简单的应用，其实完全没必要 MCP ，属于过度设计了，会引入很多不必要的复杂性；如果是复杂的应用，另当别论，不用 MCP 也得想其他办法。

其实不一定要纠结是不是 MCP ，只要能让 LLM 丝滑的使用工具（一个函数、一个对象、一个远程服务），都可以，毕竟让 LLM 原生的使用工具总比我们自己写控制逻辑要方便多了（当然也有风险，都是两面性的），这就是最大的好处，当然过程中慢慢肯定会涉及到工具过滤、结果校验等等一堆工程上的事情，这是必不可少的，小的时候一般不必纠结。

chak 这几天会做一个更新，让 mcp 这事变成一个可选项，而不是必选项，一个函数、一个 object ，都可以传给 llm 让它调用，不必那么复杂的搞一个 server ，太麻烦了，大家帮忙关注下，帮我点个 star 啊，哈哈哈哈，感谢感谢

https://github.com/zhixiangxue/chak-ai

@chenluo0429 MCP 在设计上是希望解耦 LLM 的所有依赖的，比如 resource 本质上是为了解耦上下文、prompt 是为了解耦输入，tool 是为了解耦工具调用，但是说实话，我个人感觉 resource 、prompt 这两个的设计有点远了，等工程复杂到一定程度，且，那时候 MCP 还活着的话，兴许会有用，现在，感觉是鸡肋的多数，实践上也很少听到用这个的

@Scarb 感谢阅读

是这样的，不能说是个伪需求，我觉得应该这样看：

1. 是不是用得到，有些场景可能是短平快的，通常不需要压缩模型表现也会很好，压缩了反而会丢细节
2. 如果用得到（多数情况下其实无法人为判断是否会用到），就要看具体的对话性质，需要保留哪些需要使用什么样的策略，只有业务方最清楚，不过 chak 提供了几种通用的、开箱即用的方式，不过也是支持自定义的，继承个基类自己实现就行了
3. 即使用了，也是不够的，压缩摘要只是前置的一种手段，孤立的手段并不能构成绝对有效的结果


作为一个框架，其实这些都是基操，我搞这 chak 也是因为 langchain 其实对于我搞过的很多场景来说还是太重了，一个简单的 mvp 结果要搞半天，但是 langchain 或者 langgraph 的 node 里面如果使用 chak ，还是非常方便的，否则我就得自己在 graph 里面反复的造轮子，管理上下文、管理工具调用

langchain 和 langgraph 很强大，有时候杀鸡不需要用牛刀，语法太复杂学习曲线太高了，没有必要，就像 urllib 能搞定所有的 http 请求，但是太麻烦了，requests 就满足了绝大多数的需求了，接口简单易用凭直觉就能快速用起来


一切看场景吧，定位不一样哈，chak 显然是搞不定也不会搞复杂的编排的，这不是 goal

不会和 AI 协同写代码才值得焦虑吧哈哈

@ITisCool
@BeautifulSoap
@ITisCool

更新了，支持 mcp 了，兄弟们： https://github.com/zhixiangxue/chak-ai

期待你们试用一下

function call 也好、MCP 也好，也是个话题，而且是个很大的话题，demo 貌似都能 work ，一旦想认真用，就一堆问题，这也是让我很烦的点，正在 coding 中，希望能让 fc 或者 mcp 也做到 “不用管”

@BeautifulSoap 还没发呢哈，估计就这几天就支持了，有什么需求欢迎随时给我 issue ，哈哈哈，感谢关注