pmpmp

@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

@avonhermit 这个不知道，修改代码/编辑文档这种事情大概率肯定是一个 Agent ，不过把 Agent 包到一个 MCP 里面去作为一个远程服务也有可能，毕竟可以不依赖本地软件升级，热更新 Agent 什么的也更方便

@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 协同写代码才值得焦虑吧哈哈