KaiWuBOSS

@stone981023655 嗯 说到底 我还是认为这是个技术交流区，可是说实话，交流的少，关注这些的会比较多。我其实更想聊聊 这类产品有人做过没，坑有没有 ，怎么解决，比如我现在难点就是机制都测试通过了，但 swe 通过很低。没人能沟通交流，虽然已经 500 星了 ，但没人能帮我，只能自己和 ai 慢慢一个个 eval 去跑，找问题

@COW 其实这也是没办法的事情，坦白说 我对代码细节不了解，我用了两个月 vibe 我对大框架和一些专有名词能理解，但是具体用什么理论实现什么工程 只能依赖 ai 。所以 readme 你让我自己写 真的有点为难。
嗯 我持续学习，尽量后面能让读者都能读懂。

@AlexaZhou TSP 最有价值的场景是：多个 Agent 共享同一套工具、需要跨机器远程工具调用、工具层需要严格沙箱隔离（比如云端多租户环境）。kwcode 是本地单用户工具，这些场景都不适用。
什么时候 TSP 有价值
如果未来 kwcode 做云端多用户部署，多个用户的 agent 跑在同一台服务器上，需要严格隔离每个用户的文件系统——那时候 TSP 的沙箱机制就很有价值，值得引入。
我持续关注项目 谢谢提醒

@KingGaruda 对的 现在只针对 vibe code 。python 一个语言。
另外你的观察很准确，ground truth 的问题确实存在，
但飞轮的验证标准不是人工标注，而是 pytest——
代码跑绿就是客观的 ground truth ，这是工程上
可以自动化的。

关于元专家的问题，你说得对，任务划分和合并
不应该让 LLM 做，KWCode 里这些都是确定性代码
（ Locator/TaskCompiler/Orchestrator ），
LLM 只做 Gate 分类和代码生成这两件工程做不到的事。

你的直觉是对的：能工程化的就工程化，
LLM 是最后的手段，不是第一个选择。
这正是这个架构的核心思路

@beiyanpiki 是的你提醒我了 不能为了做 swe 来做项目

@beiyanpiki 嗯 怪我 我太懒 让 ai 写帖子。下次一定好好审视。现在可以谈实现方面吗？你觉得哪些可能有机会能帮到这个项目吗？

@KingGaruda 谢谢提醒 我说下我的理解 你的理解建立在 react 框架下 框架调用大模型全流程实现任务。这个模式下小模型确实拉跨。但是我们换个框架呢？如果有套元专家组，他们把代码做了，llm 只做调用校正和测试。这个对 llm 要求就不那么高了。这个理论现阶段实现的项目很多了

@mowentian 哈哈 感谢大厂关注 已经有老师加我了