dacapoday

@dyikai 作者完全不懂 KISS,对各种范式(过程,对象,函数式)都停留在粗浅的概念,还不太能融合贯通. 更别提写的那个搞笑论文,开篇连 agent 真正问题和需求都分析错了. 说好听点是想得多,做得少. 实现上把一个初学者能犯的错误都犯了. 如果只是学生作品,还情有可原,但就这 AI Slop 居然还好意思投流推广. 过去要是人工编码, 早被自己愚蠢的设计累死了, 也就靠 AI 能糊出一个勉强运行的产品.

@dacapoday 一旦限定自己的视野, 一个没有最优解的问题,出现了唯一解.

突然理解"贸易保护主义"了, 一旦限定"国内",就只能矮子中拔将军. 反而只有"烂得出奇"的 dsh 可选.

核心在于业务是如何在人脑中呈现的，如果不再关注代码本身，又如何指导和感知 产品应如何发展，结果是否符合预期？
我觉得 code 不会消失，虽然不再人工编辑，但作为与机器交流的精确表达，可作为解歧的最终一致，类似宪法原文。实际开发确实转向人人间的沟通，甚至用户驱动开发。工程师则汇总请愿，监控导向，防止异常。

实用, 以前一直靠脑补来实现这种聚焦的.

尝试硬套一下商业模式画布，你处在供应商的位置。客户不掌握，渠道不掌握，需求也无权定义。业务和资源都被人拿捏，随时被怼 bug ，然后借机压价，让出股份，直至免费打工做 demo 。
应该一开始就以了解需求，改进软件使用的名义，直接找客户面谈，哪怕付费咨询。对接真实的市场，想办法和萍萍那些微信好友和群直接链接。

@actors111 状态都在 ctx 里，协程是无状态的，启动后从当前 ctx 恢复。实际上 ctx 的数据结构设计非常重要，agent 一侧的 ctx 不是 api 里那个简单的多轮对话历史。不仅含 cache,model provider 等 api 调用相关的参数，由于上下文窗口的存在，对话被切成多份 ctx ，中间用压缩关联。还有 branch 或 subagent 。后端要持久化，还要支持全文搜索。当然插件的状态也在其中，对于磁盘来说不会是一个简单按行追加的日志文件。这也是一些 agent 软件转向使用 sqlite 来表征。

反正都是把钱给银行,存款拿利息,买银行股拿分红.这算赌博吗?赌银行不挣钱不分红甚至倒闭?