langlang280025

@MindMindMax kiso 追求的不只是更省 token ，而是更高的 vts ，也就是用更少的 token 完成更多可验证的任务，目前和 pi 省 token 情况互有胜负，原生支持 ask user 和 subagent

@crazy0x 这点我基本认同，很多思想本来就来自可靠系统和工作流设计，所以我一开就说这可能是重复造轮子，kiso 也没打算把它们包装成新发明。我的兴趣更多是把这些取舍落成一个具体的 Agent runtime ，并把边界和失败语义做成可验证的 contract 。至于这层抽象最终值不值得，还是让真实使用和社区反馈来判断，比我自己定义更有意义。kiso 会继续迭代，希望可以和开源社区碰撞出更有价值的版本～

@vexify 额 还没适配 windows ，我的开发任务实在是太重了，我会尽快完整接下来的 todo ，然后准备适配 windows

@kidult 哇 感谢 豁然开朗 我甚至想给你置顶 可惜 v 站没这个功能

@crazy0x 你说的是 readme 还是本文啊，readme 是 fable 和 opus 写的，确实需要优化，本文是我写完初始草稿然后 AI 润色，然后我又修改的，本文我觉得还是有点价值的，因为他就是我的开发过程，如果你还是没办法直接读本文的话，上面做过总结，可以查看

@Hi3333 我觉得不同的组织、个人，本来就会对 Agent 有不同的理解和工程取舍，这也是技术发展的正常过程。

Agent 框架的意义，一方面是把模型调用、工具、状态、上下文、权限、恢复这些通用能力抽出来，让开发者可以更快地做自己的 Agent 产品；另一方面，我也不觉得“重复造轮子”一定是坏事。很多新的工程思想，本来就是在不同实现不断碰撞、验证之后才逐渐收敛出来的。

像 pi 、Kiso ，或者其他框架，本质上都在表达作者对 Agent 应该怎么工作的理解。大家把这些思考公开出来，哪怕最后其中很多代码没人直接使用，甚至只是变成了后来模型和开发者学习的材料，我觉得也依然是在推动这个领域往前走。

至于具体用在哪，我觉得不一定局限于写代码。Coding Agent 只是目前最容易验证、工具链最成熟的一类场景，Agent runtime 本身可以承载的范围要更广。

@a4545645 嗯嗯 感谢你的建议 后面我会优化下 readme

@coosir 确实需要先声夺人，这样才能在大家有限的注意力里，留下点印象🤣

@dd864140130 对，这个建议很好。Kiso 现在肯定还不完美，sandbox 、memory ，包括 benchmark 的覆盖面，后面都还需要继续补强。

之所以选择现在 launch ，而不是等所有东西都做到自己觉得“足够完整”，一方面是因为 0.40 对我来说已经是一个阶段性工作的总结；另一方面我也越来越觉得，一个健康的开源项目应该在还不完美的时候就尽早面对真实用户。否则很容易变成自己自嗨式定义“什么叫强、什么叫好”，最后社区并不一定认可，那就真成闭门造车了。

所以这次 launch 对我来说也不只是发布，更是开始接受外部反馈。你提到的这些方向后面都会陆续补上，感谢建议，也欢迎继续拍砖:—）