Reorx’s Forge

madeye 出品，懂得都懂 https://github.com/madeye/BaoLianDeng

惊了，今天走高速加上开空调竟然只有 16.5 kWh 每百公里的耗电，平时都是 18-22

看到一个有趣的工具 issu, 思路是用 CLI 和 markdown 文件作为项目的 issue tracker, 比单纯的 TODO 文件更适合一人维护项目，也很方便 agent 操控。不过这个软件是付费的，说实话我并不排斥付费，但这让我开始思考一个问题，在创造软件的成本被 AI 大幅削减的今天，纯本地付费软件的价值是否在变得越来越弱？以及如果一个人仅根据付费软件的 文档就让 AI clone 了一个功能完全一样的版本出来，是否算是一种知识产权的侵犯？ 为了做这个实验我给了 claude code 两段提示词让它来 clone 一个完全一致的版本出来: fetch all the content of https://issu.dev/ and each page of https://issu.dev/docs/ , save them to refs/ dir then read and understand all the feature of issu, the cli issue manager, to create its clone, issuka requirements: - use plan with files skill, plan first then execute - create complete test suites according to the features described in refs/ - stop unless all features are completed and all test suites are completed - use python and uv to develop, load python related skills to write code - be smart, make decisions yourself 做完之后的对齐: since our project issuka is a clone of issu, i want to you to test against it side by side with actual issu's behavior, our goal: 1. ensure all commands and options issu has we, and the behaviors are the same 2. ensure issue files manipulated by issu are the same as we do, like creating, updating, setting status, all have the same effect i have created ../issu-example folder, with issu executable in it, you should test running issu there, and compare the issues it creates with the ones issuka created here in our project write a special test suites to prepare clean dirs and run both commands and check if the results are the same use planning with files to plan and execute

把本地开发模拟 https 域名的工具从 localias 换到 portless 了 https://github.com/vercel-labs/portless

https://github.com/laosb/agentc 之前借 @hatschannel 寶地推銷了一下自己寫的 claudec ，用來快速在Apple Container裡面啟動一個Claude Code並自動把當前目錄mount進去。 一個禮拜過去，現在它已經從一個shell script變成了一個full-on CLI tool written in Swift，支援了Linux，支援用Docker(-compatible)的container runtime，並且開始以configuration file的形式支援任意coding agent CLI（目前我加上了我自己也在用的GitHub Copilot CLI支援）。 在我自己使用的過程中，我也加上了mount更多folder、排除特定subfolder的能力。 這個專案現在改名 agentc ，希望對大家也有用。

每次阅读兄台的长文推送，都让我对 go 开发产生深深的忌惮，虽然我也是从 2016 年就开始用 go 做严肃商业项目了（2021年之后就没怎么用了），但看到今天还有这么多堪比 C++ 的复杂调优还是感到自己就像个新兵蛋子 https://t.me/TheB1ackParade

AI 时代独立开发的思路，大厂把什么往云上做，我们就把什么往本地做。比如 Anthropic 今天发布的这个 Managed Agents https://fixupx.com/claudeai/status/2041927687460024721?s=46

https://impeccable.style/

https://aws.amazon.com/blogs/aws/launching-s3-files-making-s3-buckets-accessible-as-file-systems/

精准，实在是太精准了，绝对是比 harness 更好的概念。以这个定义来看，agent = LLM loop + context compiler ContextChef 的定位是 context compiler，不是 Agent 框架。 它不接管控制流，不决定何时调用模型、何时执行工具、出错了怎么重试。它只在一个时间点介入：你准备好了所有的原始状态（历史、工具列表、任务状态），准备发出 LLM 调用的那一刻。在这个时间点，它把你的状态编译成目标供应商的最优 payload。 ContextChef (1)：为什么要"编译上下文" 不过读到后面发现作者想要在这个 agent context 解决方案中塞入的模块和概念太多了，总感觉还不是最好的出路，但整个项目的宏观定位和对问题的思考仍然非常具有启发性。而且可以和 tape 相辅相成，一个定义行为模式，一个定义数据模型。

其实 Claude Code 选择闭源从一开始就埋下了不可信任的伏笔。这本是很容易预见的，但在最开始，它的工程实践走在最前面，加上模型算力充分，因此我们只看得见它的优点。再次印证了一个人性的思维特点，当一个东西效果特别好，，人会选择性忽略它的隐患，只相信自己愿意相信的意见。 Harness 一定得是开源的，就像 opencode 和 codex，这才是能持续托付信任的工具。LLM 本是已经是黑盒了，我们不知道供应商会做出什么降级和超售，唯有在端测，在 agent 运行逻辑上做到有自主权。如果两者皆不可控，当我们对 coding agent 的依赖越来越深，有一天会忽然发现自己被深度 vendor lockin，身处镣铐之中难以脱离。所以我打算从现在开始逐步 opt-out claude code, 降级 plan, 将工作流向 codex, opencode 等更加开放的工具迁移。

A Short Hike 猫咪版，等不及要玩了🥹 https://www.bilibili.com/video/BV1sBDhBxEoc/