Koike @koikedev

@dingyi 真有必要用agent浏览器么，任意Chrome内核的浏览器加插件一样能干，之前自己写了一个开源了，支持BYOK，随意使用，不比ego差。pie.chat

@eg0rev @bot I think AI Browser is useless, many plugins in Chrome web store can do better.

花了一个晚上把项目 GUI从 Tauri 重构到 Electron。 写了多年后端，对于前端选型确实是难以抉择，之前听说 Tauri 性能好，初期就上 Tauri，后来又因为各种兼容问题，开始怀疑这个决策，纠结了半个月才下定决心重构到 Electron，牺牲了一些包体积换来了稳定和兼容性，性能也没打什么折扣，还是很划算的。

最近尝试在尝试在项目里，落地人和bot（此处非Grok bot）组建群聊，人给bot发消息来安排工作，bot拉起coding agent推进项目。 以前觉得最难的是如何处理各个bot之间消息的分发，解决了这个问题之后，发现瓶颈是人，人的注意力被极大的消耗。 bot的回复太快了，一个议题抛出来，几个bot都聊了好几轮了，密密麻麻几十条消息，项目的实际状态根本没办法明确，看着密密麻麻的消息，人脑根本没办法消化。 搞不懂那些说让Grok Bot指挥Claude完成开发的人，真的是实际落地过项目吗，项目的完成质量真的足够吗，真能放心让bot来主导你的项目吗？

@fanofaliens @OpenAIDevs @thsottiaux 明天的更新内容有了✌️

@kvickart Maybe use separately workspace and git could solve this?

@TTrimoreau would you like try this？amkumo.com

在Coding场景里，用多Agent来拆解工作可以使用更低的成本，更高的速度，以及使用不同的模型智能来提高质量。比如使用Claude来做设计和工作项拆解，再接多个Agent比如使用GLM或者DeepSeek来并行的做编码实现，Codex做review。整体成本会更低，速度也更快，质量也能更好。 还有非Coding场景，比如Claude做调研，Gemini用来做文案优化等也很常见，不同模型擅长的的场景不一样，一起使用的话可以取长补短

让 Claude 重构了一下 UI设计，从昨天开始，包含设计+实现，已经吃掉了我 5 个 max5x 5h 额度，我还想怎么写个 UI 这么费劲。 今天一看，一直在给我拉子代理做实现，还用的是 opus 5.5 xhigh……

@realchendahuang 在我的项目里Agent之间可以直接互相读取上下文，在新Agent里读一下就行

@Suercha007 我是把之前自己的agent项目里的核心，抽了个轻量的sdk，后续在我的其他项目复用，引外部的agent也不是不行，但一是太重，二是不好针对性做优化。反正自己玩，也没啥成本

5/ Kumo is a Mac workbench for running many coding agents side by side, each on its own git worktree. Free during the beta, until Nov 1. amkumo.com

4/ It draws as it writes. The script only runs once the block is complete. Each widget runs in a sandbox with no access to your conversation or to Kumo. A button can only fill your draft, and nothing is sent until you press Return.

3/ Same trick on every backend. Four agents, four questions, sent at once:Codex ranks the files that need tests Grok reviews a commit, diff and fixes included Copilot puts the release on one board OpenCode lets you drag a slider to size a cache

2/ In the video, example as search feels slow. Claude reads a week of nightly benchmarks and the git log, then draws it: p95 jumped from 118 to 428 ms the night a fuzzy-search commit landed. One click on "Fix the search regression", one Return, and search comes back 16× faster.

Meet Kumo 0.33: your agents can answer with a live widget. Just say "show me in a widget" and Claude, Codex, Grok, Copilot or any of 15 agents draws a chart, a board or a slider in the chat. Its buttons write your next prompt. You press Return.

？还有黑科技？

Reason @reasonmachines

2 weeks ago

Introducing Reason: A state-of-the-art harness on cost efficiency for free Beating Codex+Astra on Terminal-Bench 4.0 while being 22% cheaper.

178 176 3K 682K 2K

gen ui 还是有点意思的，研究中

最近看 yetone 基于 loop 的 ai 工作流，想到今年 6 月份我在小红书上发的关于 Loop Engineering 如何落地的文章，转到 X 上来跟大家分享一下我的理解。 我在今年 5 月发布了一个浏览器插件 Agent - Pie（pie.chat）, 自认为是目前众多浏览器插件里产品设计、 Agent 的能力、稳定性上做的还是比较到位的一款产品，在 WebArena 得到 85% 的通过率，到现在也有几百个用户在使用，非常开心。 这个项目在几个月的迭代期里，基本完全基于 Claude 的云端 Loop 来完成 issue - PR - review - merge 的流程，可以从项目的issue 和 PR 里看到运行的痕迹。 我认为自动化开发是未来众多开发人员思路转变后的必然结果，只是可能部分人先走了一步。 在 Loop Engineering 火了之后，龙虾的作者@steipete 随后提出过所谓「Graph Engineering」，在我看来也是必然，而且也不是复杂的概念，我自己是大数据工程师出身，对这个已经熟悉到不行，GE 就是一个流式系统。 因为 Loop 只是一个节点，而开发流程是一条线，实际的流程里 Loop 和 Loop 之间必须要通过事件进行传递，否则只能通过卡控时间来对两轮 loop 的产物进行衔接，错过了这一轮就只能到下一轮再取回上一轮的产物。 所以 Graph Engineering 的形态就是一个DAG，串联起来每一个 loop 节点，并通过事件来传递每轮 loop 的产物。 这也是为什么我做了 amkumo.com ，目的就是把loop做成流，完成整个自动化流程的串联，这个功能我命名为 Agentflow。 迎接 AI 自动化开发的时代吧，大伙有啥想法都可以聊，互相学习。 以下是原文： ``` 我想聊一下最近在实际开发过程中，对于 Loop Engineering 的一些思考，以及如何落地。 看过一些资料后，我理解现在普遍的认知里，对 Loop Engineering 的定义更多是设定一个目标，让 Agent 通过不断的迭代逐步向目标靠近。我觉得这只是目前一种普遍的使用方式，或者说是广义上的认知。 但在实际开发流程里，其实很难落地，核心的问题是目标怎么定义，完成一个feature，或者修复一个bug，快的几分钟或者数小时就能做完，剩下的时间就是空转。如果定的比较长远或者不具体，Agent自己容易走偏或者不知道怎么完成，人类如何干预。 我的设想，是把Loop单元化，并通过不同Loop的组合，来共同完成一个复杂的业务。 我想先介绍一个DAG（有向无环图）的概念: workflow本身定义出来了一个图的结构，包含节点和有向边，如果这个图里没有构成环，那么从图里的入度为0的节点顺着边往下走，必然会走到一个出度为0的节点，一条在DAG里流转的事件也是如此。 要实现上述的能力，Loop单元需要满足: 1. 持续有新增的输入来源。我称其为“事件”，可以是已有工作项的进展更新，可以是新的目标 2. Loop内每次执行的目标是稳定的。借助LLM，Loop内甚至也可以做到很复杂，甚至可以是广义上Loop Engineering的完整流程 3. 事件流转机制。当前Loop要对事件做变更，并流转给下游的Loop 实践上来说，我搭了一套基于 Loop 的产品迭代的流水线，这可能也是 Loop Engineering 的一种具体的落地方式。虽然很多人可能有过类似尝试，我还是想简单分享一下我自己的设计，以及谈谈Human in the Loop。 目前在开发工作中，我搭建了三套 Loop，每个 Loop 各司其职，并且借助中间件互相衔接，并且明确人在其中的位置： 第一个 Loop（最上游）： 主要负责 Issue 的“分诊”。它会定期扫描新的 Issue，自动完成分类、分级以及打标签的工作。这是第一步的基础整理。 第二个 Loop（方案确认）： 负责制定计划或代替人工进行方案确认。它会根据 Issue 的背景信息、前置分诊 Agent 的判断以及给出的 Solution，生成一系列确认项。一旦这些项得到确认，该 Loop 就会结束。这个阶段的任务相对简单明确。 第三个 Loop（实现）： 这是一个 Implementation Loop。当上游标记某个 Issue 已经可以进入执行阶段时，它会定期进行机械化的执行与实现，并最终提交 PR。 这三个 Loop 已经在我的工作流中落地，它们代替了我之前人工处理的工作，比如 Issue 发现、需求管理，简单的指派Agent干活，以及那些需要耗费大量脑力去做判断和指导 Agent 执行的过程。 我把这些过程完全托管给了整个 Loop Pipeline。这样一来，我可以从这些繁琐的事务中抽离出来，专注于产品设计、迭代方向以及战略层面的思考，而不需要关注具体的实现细节。我觉得这在一定程度上把人的生产力和大脑资源从具体事务中解放了出来。 有意思的是，这个Pipeline搭建起来之后，就很像一个数据领域的流式系统（Stream System）。每个节点（Loop）之间通过消息队列（Github issue和PR）连接，所有事情都以“事件”的方式向下传递。这样一来，整个工作流会变得非常自然。我只需要定义好整个 workflow，每个 loop 我现在认为就是一个 function，它只负责死循环地处理固定的事情。 我认为可以继续探索，通过不同 loop 的组合，可以实现更多场景的应用。组成的流水线可以不是线性的而是一个复杂的DAG，从而完成更复杂的计算流程，需要集思广益。 ```

@surfer_tas 我现在是单独弄了一块区域来看新Agent的通知，点击了就能快速跳转过去