liuchao719

归根结底是身处在要求严谨的评价体系中，没有信心创作非严谨内容（因为这可能遭致恶评），但大众环境对结果更为看重（可以看成另一种要求结果的评价体系），两者评价体系不同，导致作者很难创作出符合另一种评价体系的内容，所以不必太过否定自己，换个环境会好起来的。

> 如果大家有时间看到这，可以给我提一些意见，告诉我如何才能在尊重 eval 和 benchmark 严谨性的同时更好的推广我的产品。 我知道用 codex 或者 claude 写一个 coding agent 很简单，但我也相信，总会有人理解 benchmark 和 eval harness 的价值。

我在这里和你有一点不同意见，原因和上面的回复类似，如果你想获得更多的 star ，更多的传播，就要从传播学/心理学入手。我认为大众在 star 或者评论转发，或者微信里讨论的时候，是不会在意严谨性的。所以如果卸下一丝严谨性的包袱，能更好的达到你的目的。一个我自己悟到的，严谨代表着能获得喜欢严谨人群的认可，但大众通常来讲是不严谨的，不是作者傲慢，是作者在满足自己的品味和达成自己的目的之间，两个都想要。

lz 的想法真是很天才的，阅读了 readme 获益匪浅，感觉可以到被 openai 和 anthropic 收购的程度（但也侧面反映了这些家伙对于 token save 一点都不在意）

我作为一个用户，讲一些我看到这个项目的心理变化，希望对 lz 的困惑有所帮助

首先我没有在第一时间理解，我要怎么用这个，它是谁的代替品。我可以像 claude code/codex ，或者是 claude desktop or Orca 还是 workbuddy 等等的产品一样使用它。（虽然我通过完整的阅读 readme 知道了问题的答案，但如果好奇为什么你声称找到了真的节省 token 的办法，我是没耐心读下去的）

其次我读完之后也并没有要安装的想法，这一方面是因为我目前对 tokne 的消耗量并不大，另一方面是，我没有直观的看出 80%，16% 这些数字对我来说意味着什么。可能是能让我多 vibe 一会儿？多产出几个项目？但是思考这些问题，就会实打实的阻碍我产生安装的动作。最直白的建议，把 token 等价的美元，在用 codex 和 tura 之间比较，告诉人们能多蹬出多少美元，这样非常直观。

最后，我想起来了我以前的一个作品，https://github.com/chaoliu719/splitpatch ，它也是把原理放在了里面，甚至放了一个示例来讲。我今天整理 github 的时候，突然觉得我写这些更适合放到 blog 中，而不是 readme 中，readme 更多的是宣传，安装，快速上手，而不是原理解释。当时我真的很想把这些讲清楚，让大家看到这个项目的价值，但今天来看，我想问当初的自己，为什么用户需要关心这些原理呢？他们只需要最浅显易懂的 CTA ，他们只是 user 而不是 developer 。我没有动力改我的项目了，因为它很小，但是我觉得你的项目真的值得好好宣传一下，它真的很有潜力。

短期内的技术门槛降低，一大波人眼红，衍生出各种场景，然后就会有各种专门的商家针对性搭建服务，精准对接一波，然后龙虾死掉。

感谢 已领

目前无论是我自己用 AI ，还是观察别人用 AI ，都有一个核心问题：当前 AI 无法感知到所有执行环境。比如一个 API 不通，究竟是网断了？还是梯子挂了？还是服务有问题？可能我们刚好忘记告诉它了某个事实，导致它在执行的过程中一遍遍尝试，浪费很多 token 和时间。但如果 AI 能够“浅尝辄止”并向上反馈，再结合自总结 skill 的机制，把人类的反馈记下来，我觉得 AI 未来应该会是很好的助手/帮手，而非仅仅是一个高效率的执行者。

@d0r1an 我有了一些新想法：
理想状况下 Agent 是一定要完成任务的，但是考虑到现实情况，有可能我们也不能清楚 Agent 能不能完成任务，只是先把任务交给它试试（比如大部分不懂技术的人用 clawdbot 的时候）。这时我们不是想让 Agent 一条路走到黑，然后告诉我他干不了，而是希望 Agent 在执行的过程中，如果过于困难，就向上请求支援。

这个机制还可以应用在多层 Agent 架构中。面对复杂问题，首先分散出一堆子 Agent 探索，子 Agent 如果过于困难，则向上汇报，主 Agent 再根据子 agent 执行结果，综合评定最小解决代价后继续灵活改变计划，或寻找其他解决方案。

@d0r1an 之前不是有人指挥好几个 Agent 干活，人只需要像自己有点像 leader 一样规划就行。其实这个思路是把 agent 作为 leader ，让他去安排一些子 Agent 去做细分的活儿。这样子，Agent 就能够自己去处理一些不确定性的东西，减少了上层 Agent 的一些认知负担。可以嵌套两三层这种架构，专门拆解复杂问题。但我这个想法应该是去年的，现在应该已经有类似的 Agent 架构出来了，只是我还没时间去研究。

然后最近不是 skill 很火嘛，然后还有那种自学习的 skill ，其实对于一个层级上的子 Agent 来说，如果每次划工分给他的问题是合理的，那么我觉得他很快就能自学习出一整套 skill 来，其实很像公司的架构了。

和我之前的一个想法特别类似，agent 现在要处理的逻辑层次太多了，每一层都会带来不确定性。或许还有一种思路是，每次遇到不确定性就分配一个 subagent 处理不确定性。因为与其手动封装各种可重入节点，不如让 llm 自己去划分任务的逻辑层次。