langlang280025

@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