seedance 有啥便宜的渠道吗 可以加个好友聊聊吗

@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 对我来说也不只是发布，更是开始接受外部反馈。你提到的这些方向后面都会陆续补上，感谢建议，也欢迎继续拍砖:—）

@tuangouzi py 和 ts 都可以做 Agent 。早期很多 Agent 框架本来就是 Python 生态出来的，现在模型能力也很强，语言更多只是工具。

我觉得真正值得学的是 Agent 工程背后的东西：模型怎么和工具交互、状态怎么管理、出错怎么恢复、上下文怎么控制、effect 怎么安全落地。这些技术视野很难靠看一两篇教程建立起来。

如果给一个建议，就是多看优秀的开源项目，直接读它们为什么这么设计，比如 pi 就很值得深度阅读

@woshishui2022 好项目 值得学习 这就是开源的意义啊 不开源我都不知道这个项目

换个非 Coding 场景可能更直观。比如支付 Agent 发起一笔转账，本地已经记了 Started ，银行其实已经扣款了，但客户端这时断线，本地没拿到 Receipt 。重启后，“没收到成功”不等于“转账没成功”。

这时候如果直接重试，可能扣两次；如果直接当成功，也可能其实一分钱没转出去。Kiso 处理的就是这种状态：结果未知就明确标成 uncertain ，等确认，而不是让模型根据上下文去猜。

你这个例子因为是人为按顺序 stop ，宿主和模型确实还能从上下文推断； Kiso 主要是防这种没有人来得及留下解释的 crash window 。

@dabbit 你这个例子里我同意，主动 stop 后宿主把中断信息告诉模型，模型一般能自己接上。Kiso resume 主要解决的不是这个，而是进程直接死亡后的“事实恢复”：比如 shell 已经开始执行，但进程 kill -9 了，结果没写回来，这时候模型没法知道副作用到底发生没有。Kiso 会持久化 execution start / receipt / approval ，成功过的不重跑，结果未知的标成 uncertain 让人裁决，而不是让模型猜

@Cynicsss 这里的“强”主要指 runtime / agent 工程能力，当然工程能力也可能是主观的。不是模型本身更聪明。launch 前我们用同模型、同 ds v4 flash high effort 、隔离环境和 pi 0.84.2 做了 48 对 / 96 legs 的对照：跨文件任务两边都是 12/12 ，隐藏题都是 22/24 ；隐藏题里 Kiso 的 cost v2 中位数比 pi 低约 32%，T5 基本持平（-2%），24-turn 长 Session Kiso 反而高 19%。完整 bench 和协议都在仓库里。

@woshishui2022 200 行只是 read_file 的默认窗口，不是上限，支持 offset/limit 继续分段读取，显式指定 limit 也可以超过 200 。日志目前没有单独的特殊 tool ，一般先 search 定位，再按需分段读，主要是避免一次把大量日志灌进上下文

@lp7631010 同样追求，我要的是既省 token 又出活儿，随着模型智力提升，强如 Claude code ，内部也有大量的不必要的 token 损耗，当然他们不必要追求 token 效率，但是对于资源有限的开发者来说，比如我，省 token 也是一个很重要的考量

@pke 好建议，和 pi 做了一次小对比，任务完成度同模型同推理强度裸测一样效果，部分隐藏任务 kiso 比 pi 省 token ，远比 Claude code 和 codex 省 token

@wsseo 重复造轮子很爽，重复造轮子把成品拿出来给 v 友们审查，挺折磨的