这是苍何的第 617 篇原创！
大家好，我是苍何。
最近看了 DeepSeek Harness 团队的《Super-agent 设计探索，迈向更自主的 Agent 系统》，感触还是很深的。
过去一年，Agent 的单体能力在大幅增强，但很多还困在单次的对话里，切换对话，还要主动记忆上下文，而同时进行的对话 Session 一多，人的注意力就会跟不上了。
最近很火的 Personal Agent 在个人助手场景下可以持续观察信息流并协助处理事务，而且具备全局感知的上下文，是 Super-agent 比较好的一种形态。
Super agent 具体工作由多个 Worker 并行执行，各自保留独立上下文，按需连接实际的工具环境。已有任务的后续消息，还可以沿订阅通道直接送到对应 Worker，少绕一遍 Router。
底下的数据库保存会话状态，外部的 Watchdog 监控异常和执行进展。
图源《Super-agent 设计探索》，版权归原作者所有
这几部分配合起来，让系统有条件同时接活、持续执行，也能在出问题后恢复工作。
总结起来就是连续、高效、主动、持久四个词。
那落到真实工作里，怎么把一群 Agent 组织起来，让任务持续往前走？
其实我也一直在探索，我尝试过不少方法，比如在 openclaw 和 hermes 火的时候，我尝试自己动手搭建一套复杂的多 agent 架构。
但这套系统本质没解决实践驱动和自主感知决策的问题，最多算是一个简单的 multi agent 架构。
这个架构的本质是依旧需要人来做信息筛选和决策，没有基于事件驱动和自主决策。举一个简单例子，你更好理解。
假设我们现在有一个搜集热点的 agent，他会把搜集到的每日热点都丢给 team agent，team agent 需要人来确认这些热点去做选题，当这些足够多的时候，人的精力就非常有限了，有时候搜集本身就会变得没意义了。
但老实说自己搭建一套 Super-agent 又显得有些复杂，特别对于没有技术背景的同学来说，调研了一圈，现在 GitHub 上已经有一些比较成熟的解决方案了。
大家可以自行尝试，下面分享下我用 LobeHub 来搭建我自己的 Super-agent 的一些实践，希望能给你一些启发。
如果本文对你有帮助，可以点赞转发告诉我。
LobeHub 是比较早期的一个 AI 开源项目了，之前叫 LobeChat，很多最早接触 GPT 的应该都有听过或用过这个项目，我也算是很早一批的使用者了，25 年改成了 LobeHub，变成了 Agent 平台。
发展了几年，现在也已经 80 多 k 的 star 了，势头很猛。
而且我在网上看到，发现他们已经开始用 LobeHub 持续开发和迭代 LobeHub 自身了。
LobeHub 原本支持给任务单独指定模型，但只能在网页上操作，Agent 通过工具或命令行创建任务时，还缺少这个入口。这样一来，想让一个模型负责规划，再让另一个模型执行任务，就卡住了。
主管 Agent Nasa 查清问题后，创建了 T-1149 任务，把它分派给基于 Claude Code 的执行 Agent Dario。任务里写明了现状、需要补齐的入口和验收要求，Dario 接手后继续开发。
最终，Dario 交付了 PR # 21852，为内置任务工具和命令行补上了指定模型的能力。交付记录里附有修改说明、测试结果和验收报告，也列出了需要部署后继续验证的部分。
我也看了对应的 GitHub PR，里面明确关联了 T-1149，并记录了 AI 参与代码实现、测试和验证的过程，目前这条 PR 已经合并。
从发现问题、创建任务、分派执行，到提交代码和提供验收证据，这套协作方式已经用在了他们自己的研发里。更有意思的是，Agent 这次补上的，正是方便后续 Agent 分工执行的能力。
我最近也在自己的工作里尝试了类似的协作方式，比如更新我的 Codeguide 网站。
我先把想要的分工和协作方式告诉构建助手，让它帮我搭了一个 codexguide 产品研发群。
群里有 1 名主管 Agent 和 6 名执行 Agent，角色、规则和流程也一并配好了。
除了 LobeHub 的 Agent，我还接入了本地的 Codex、Claude Code，让这支团队能用上实际项目里的工具。
比如我让它对全站内容进行审查，给出更新的优先级。
主管先把内容审查交给主编：对照官方资料检查代码仓库和线上页面，整理问题证据、修改建议与验收标准。后续的实现和复核，再按各自职责交给其他成员。
先找内容主编，是因为这轮要判断信息有没有过时、结论有没有来源、哪些页面值得优先更新。我给主编设定的是默认只读的审查职责，先把这些问题查清楚；需要本地验证或修改文件时，再交给有开发环境的 Codex、Claude Code，并安排 Reviewer 独立复核。
这里的分工依据，是每个成员的职责、工具和执行环境。主管派活时，也需要把目标、输入材料、允许修改的范围和验收要求一起交过去，下一个成员才能接着做。
内容主编审查了 codexguide 的代码仓库和线上内容，把发现的问题、对应证据、修改建议和验收标准整理成报告，并安排了后续更新的排期。
报告里的信息也附有可核对的来源，哪些地方确实有问题，我可以顺着证据逐项确认，不用只听它单方面的判断。
审查中发现的问题，后面也进入了实际修改和 PR 交付阶段。
具体怎么派，可以看后面一次修复 #48 的委派记录。主管让 Codex 修改第三方 API 鉴权文档并提交 PR，之后交给 Reviewer 复核；另外两个 issue 的处理由主管自己负责。这次我没有开启群组的 Task 记录，委派过程以卡片形式留在群聊消息流里。
展开卡片，里面给出了目标仓库、基线 commit、涉及文件、主编检查到的问题、官方资料链接，以及“可以提交 PR，但不合并、不发布”的范围。主管是在把一份可以独立执行的工作说明交给 Codex。
这种交接需要明确两件事：执行者拿到哪些输入，以及这次可以做到哪一步。审查意见可以作为修改线索，涉及鉴权等技术细节时，Codex 还需要回查官方文档和当前仓库，确认建议成立。
本地环境也要接通。我顺着 LobeHub 的开源实现看了一下：以 CLI 连接方式为例，lh connect 连接设备网关，收到执行请求后，在本机启动对应的 Agent 运行流程。请求中包含 Agent 类型、工作目录、提示词和话题标识，让云端分派的工作落到具体机器和目录上。
设备连接实现：github.com/lobehub/lob…
所以，接入 Codex、Claude Code 时，要先确保本机的 CLI 能正常使用，再通过桌面端或 CLI 连接器接入设备，为执行成员配置对应环境和工作目录。能否读写文件、运行命令和推送代码，还取决于本机的文件权限、CLI 执行限制，以及 Git、GitHub 的登录与授权状态。
在我的协作规则里，执行者开工前要先读仓库的 AGENTS.md，检查 git status、当前分支和基线 commit；已有未提交修改要保留，多人同时写代码时用独立 worktree 隔离，无法隔离就先串行。允许改文件、允许 push、允许提 PR、允许合并和发布，也分别说明。这些规则需要执行者遵守，实际访问限制仍由本地环境和服务端权限控制。
交付时，我要求带回文件修改摘要、实际运行的命令与结果、commit 和 PR 链接。Reviewer 要复核具体版本；如果后面又提交了新 commit，就需要检查受影响的部分。没有跑过的测试、还没验证的页面，也要写出来。
团队提供的 Acceptance 则是另一种验收方式：把需求拆成检查项，附上实际产品的截图、录屏和日志，汇总成报告，让人逐项接受或提出修改意见。
我这次的群组规则里，先要求 Reviewer 对具体代码版本独立复核。需要验收页面表现时，还可以把截图、录屏这些证据一并纳入。
Acceptance 开源地址：github.com/lobehub/acc…
而这轮审查也让我看到，网站最大的问题还是内容的时效性。
Codex 官网有了新消息，我忙起来没及时同步，网站的信息就会慢一拍。这次把已有问题改好了，后面有更新，还是得有人持续跟进。
于是，我又让它加上自动巡检，把这次检查变成定期执行的任务。
主管分析需求后，将内容比对交给内容主编，将定时巡检交给 Lobe 助手。后续就可以按设定时间发起检查，减少我手动跟进的次数。
这项巡检也不只是设个时间就结束了。任务状态、数据来源、对照对象、检查范围、交付内容和授权范围，它都逐项配好了，让后续执行有明确的依据和边界。
这项每日巡检被建成了独立的 T-2 Task，设定在北京时间每天 9 点执行。任务页里已经有首轮和第二轮的运行记录，主管、Lobe 助手与内容主编的交接评论也留在下面。
从内容主编自己的页面看，还能找到“来源：任务”的执行话题。Task 承载持续巡检这件事，每一轮执行则有自己的话题记录。一次话题归档后，后续巡检仍然需要按计划继续。
这也解释了我什么时候直接委派成员，什么时候建 Task：当前群聊里已经明确的工作，可以通过委派卡片交给对应 Agent；像每日巡检这样需要反复执行、跨天保留检查进度的工作，就更适合用独立 Task。后面如果要管理更多依赖和复核轮次，我也会优先把这些工作放进可持续跟踪的任务里。
上下文交接也有具体落点。这次的长报告保存在内容主编的 Agent Documents，链接贴进任务评论；代码变更留在仓库和 PR；后续巡检则被要求从评论里的检查进度、未解决项和报告链接接着查。按这套分工，可以这样组织交付：
这里还遇到了一个真实问题：内容主编打不开预期的巡检父文档，工具返回了 Document not found 和 Parent not found。它把本轮报告暂存在自己的 Agent Documents，再把链接和阻塞原因写回任务评论；预期归档文档的进度与索引没有更新。
主管随后要求，后续轮次先用任务评论保存检查进度、去重线索和未解决项，再尝试建立可用的归档位置。这能先把工作记录接住，但另一个 Agent 是否读得到报告，仍要实际打开验证。文件存好了、链接传过去了、接手的人能读到，是三个需要分别确认的环节。
复核配置也有类似的细节。记录里，Lobe 助手尝试设置独立 Verify，写入后再次查询却显示 not configured，于是转而配置任务 Review，设置 autoRetry=true、maxIterations=2。这些是配置交接记录，首轮还没有独立判定单，因此不能据此认定已经复核通过。
对于 PR 被打回、依赖变化或执行失败，我在协作公约里约定了处理方式：把失败原因和证据留在原任务，修复后提交新版本，再按新 commit 复核；上游结论变化时，重新检查受影响的下游工作；缺权限或需要扩大范围时，先报告阻塞，再由主管协调或回来找我确认。
LobeHub 也支持由消息事件触发工作：先根据频道范围、关键词等规则筛选，再由模型结合 Agent 的职责判断是否需要介入。比如群里有人反馈了一个缺陷，符合条件时，就可以触发后续处理。
这也让我觉得，“主动”需要把条件说清楚：什么时候检查，遇到什么情况介入，可以处理到哪一步，哪些地方需要回来找人确认。把这些配好，再看每轮执行留下的证据，才能逐步把持续跟进交给它。
除了跟进官方更新，我也想给网站补充一些实际使用案例，就让它去 X 上找值得参考的 Codex 用法。
它检索后整理了一批案例，并逐一给出推荐理由，方便我判断哪些值得进一步研究和整理。
它还查看了一个我好久之前提的 issue，并在里面做了详细回复。
这一步对我有用的地方，是判断依据和后续建议都留在了原来的问题下面。之后再处理这个 issue，我可以顺着记录确认进展，相关信息也更容易找回来。
除了网站维护和问题排查，我最近做短视频需要的选题调研，也交给了 Lobe。
我让它分析抖音上 AI 工具、AI 效率和 AI 编程相关的作品，看看这些视频有哪些值得借鉴的做法，再结合评论区，整理用户的真实需求。
接到任务后，Lobe 把调研拆成了两条线，分别创建子助理，并行检索 AI 工具与效率类内容，以及 AI 编程类内容。
执行过程中，右侧面板会显示当前运行的任务及其资源占用，还能查看本地电脑的 CPU、内存和磁盘使用率，让我知道任务在怎么跑、电脑的负载如何。
如果想看具体进展，点开子助理，就能查看它的执行过程和输出结果。
两条线的调研完成后，Lobe 把结果汇总成了一份分析报告，既比较了账号体量和视频数据，也分析了各条视频的内容深度、标题和评论反馈。
在这些信息的基础上，它进一步梳理了每条视频的内容类型、可能带动传播的因素、值得借鉴的做法，以及评论区透露的需求信号，再整理出选题策略、推荐的视频结构和需要避开的坑，把对标分析接到了后续的内容创作上。
在这份分析报告之外，它还把建议整理成了一份实战手册，从账号冷启动、可以直接上手的选题，到脚本撰写、不同类型视频的拍摄和后续复盘，都给出了具体做法。这样，前面的对标分析就不只是供我参考，还能接着用来安排选题和拍摄。
整个任务跑了大约一个小时，从两条线的检索分析，到报告汇总和实战手册，都接着做了下来。最后交到我手里的，既有分析结果，也有下一步可以动手做的内容。
交办任务的入口也可以放到平时用的聊天工具里，比如我把它接入了微信。
我在微信里让它帮我找一下 X 上最近一周使用 opus 5.5 做视频的优秀案例。收到需求后，它分配子代理，开始搜索。这样，想到一个要调研的问题，在微信里就能交办下去。
实践下来，我感受比较深的是，前一步做完之后，工作有机会接着往下走了。
网站审查里发现的问题，接到了实际修改和 PR；担心内容过时，就继续配置巡检；短视频调研完成后，又整理出了可以拿来安排选题和拍摄的手册。
单个 Agent 再强，困在单次对话里，工作就断在对话边界。有了主管分派和任务衔接，前一步的产物变成下一步的输入，任务才有机会自己往下滚。
回过头看，我最早自己搭的那套多 Agent 架构，其实卡在同一个地方。
搜集热点的 Agent 把结果丢给团队，等人确认选题，人一忙，整条线就停了。
没有事件驱动，没有自主决策，人成了瓶颈。
现在有了主管分派和任务衔接，我可以把更多注意力放在目标和结果上：哪些内容值得更新，哪些选题适合我，交付有没有达到要求。
当然，这些判断还是要自己做。任务开始前，把目标、范围和验收要求讲清楚；结果交回来，再顺着证据检查，提出具体的修改意见。
在这套系统中 Super-agent 的「主动」显得尤为重要。
什么时候检查，遇到什么情况介入，可以处理到哪一步，哪些地方需要回来确认。
条件不讲清楚，主动容易变成添乱；讲清楚了，每轮执行又都留了证据，才能逐步把持续跟进交给它。
说实话，用了这段时间，我对 Agent 的理解变了。
一开始总以为，用 Agent 就是把自己「替换」掉了。
后来才发现，根本不是这回事。
那些重复的、靠信息量驱动的执行任务，确实可以交出去。剩下的，反而是更需要我的部分：判断值不值得做，结果有没有达标，下一步往哪走。
Super-agent 帮我把时间还给了自己，让我把精力集中在真正重要的决策上。
LobeHub 自己用 Agent 开发 LobeHub，也应征了一些事。
Agent 补上的，正好是方便后续 Agent 分工执行的能力。
自己跑通自己的流程，再让流程帮自己跑得更快，这种正向循环，才是「持久」该有的样子。
我越来越觉得，能把 Agent 用好的人，核心能力可能不是「会写提示词」，是懂目标拆解，懂验收标准，懂推动迭代。
这一套，本质上就是项目管理。
只不过，你管的这个团队，全是 AI。
你也在搭自己的 Agent 工作流吗？欢迎评论区聊聊你的实践，或者点个赞让我知道这篇有帮助。
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
This is the 617th original.
Hello, I'm God.
Recently, the DeepSeek Harness team's Super-Agent Design Exploration, moving towards a more autonomous Agent system, was deeply touched.
Over the past year, Agent’s monolithic capacity has increased dramatically, but many are stuck in a single conversation, cutting off the dialogue and actively remembering context, while at the same time, more than one session of the dialogue will follow.
Recently hot, personal Agent has been able to keep an eye on the flow of information and assist in handling matters in a personal assistant setting, and context, with a global sense, is a better form for Super-agent.
Super agent works in parallel with multiple worker, each retaining a stand-alone context, linking the actual tool environment as needed. Follow-up information on a given assignment can also be sent directly to the corresponding Worker along the subscription channel, less by Router.
The database below saves session status, external Watchdog monitors anomalies and implementation progress.
Source Super-agent Design Explore, copyrighted by original author
Together, these components allow the system to operate simultaneously and on an ongoing basis and to resume its work when problems arise.
Taken together, four words are continuous, efficient, proactive and enduring.
How do you organize a group of Agents and keep the mission going?
I've been trying to figure out a lot of ways, for example, to build a complex multi-agent structure myself in the fire between openclaw and hermes.
But the essence of the system does not solve the problem of practice-driven and autonomous sensory decision-making, at best a simple multi-ent structure.
The essence of this architecture is that it still requires people to do information screening and decision-making without being event-driven and autonomous. For a simple example, you better understand.
Suppose we have an agent who collects hot spots, he throws the hot spots he collects every day to the team, the hot spots he needs to be identified for selection, and when there's enough, people's energy is limited, and sometimes the collection itself becomes meaningless.
But to be honest, it's complicated to build a set of Super-agents, especially for students with no technical background, and now there are more mature solutions on GitHub.
So you can try and share some of my own Super-Agent practices with LobeHub, and hopefully give you some inspiration.
If this is of help to you, let me know.
LobeHub is an earlier AI open-source project, formerly called LobeChat, which many of the first GPT contacts should have heard or used, and I'm a very early user, changed to LobeHub in 25 years and became Agent.
It's been going on for a few years, and now it's over 80 k of the star, and it's very strong.
And I see online that they've started to develop and integratorize with LobeHub themselves.
LobeHub would have supported a separate model for a task, but only on a web page, and Agent was missing this entry when he created the task through tools or command line. In this way, it's stuck in order to get one model to plan and another to perform the task.
The supervisor of Agent Nasa identified the problem and created the T-1149 task, which was assigned to the execution of Agent Dario based on Claude Code. The mission described the status quo, the access points that needed to be filled and the requirements of acceptance check, which Dario took over and continued to develop.
Eventually, Dario delivered PR #21852, adding to the capacity of the built-in task tool and command line to specify models. A description of the changes, the results of the tests and the acceptance check report are attached to the delivery records, which also include elements that require continued validation after deployment.
I also looked at the corresponding GitHub PR, which clearly links T-1149 and records the process of AI participating in code realization, testing and validation, which is now merged.
This collaborative approach has been used in their own research and development, from identifying problems, creating tasks, assigning tasks, submitting codes and providing acceptance check evidence. And what's more interesting is that Agent's addition is the ability to follow up on the Agent division of labour.
I've recently tried to work on similar ways of collaborating, such as updating my Codeguide website.
I'll start by telling the builder what division of labour and how to work together, and let it help me build a codexguide group.
One of the group's directors, Agent, and six executives, also have roles, rules and processes.
In addition to AbeHub's Agent, I have access to the local Codex, Claude Code, which allows the team to use the tools of the actual project.
For example, I let it review the entire site and give priority for updates.
The supervisor first referred the content review to the editor-in-chief: checking the code warehouse and web pages against official information, collating problem evidence, proposing changes and acceptance criteria. Follow-up implementation and review are then delegated to other members in accordance with their respective responsibilities.
The editor-in-chief of the content is first sought because the round will determine whether the information is outdated, whether the conclusions are sourced and which pages are worthy of updating as a matter of priority. I have given the editor-in-chief a default read-only review duty to identify these issues first; if local validation or modification of the document is required, it will be handed over to the developed Codex, Claude Code and an independent review of the Reviewer.
The division of labour here is based on the responsibilities, tools and implementation environment of each member. The supervisor also needs to hand over the target, input the material, the scope of the permitted modifications and the acceptance check requirements to the next member before proceeding.
The content editor-in-chief reviewed the code repository and online content of the codebook, collated the problems identified, evidence of correspondence, suggestions for amendments and acceptance criteria into a report, and scheduled subsequent updates.
The information contained in the report is also accompanied by verifiable sources, and where there are real problems, I can confirm on a case-by-case basis with the evidence and not only by its unilateral judgement.
The issues identified in the review were followed by practical modifications and PR delivery.
Specifically, you can look at the assignment records for a later fix #48. The supervisor asks Codex to modify the third-party API assurance file and submit it to PR for review by Reviewer; the other two issues will be handled by the supervisor himself. This time I did not open the group's Task records and the accreditation process was left in the chat stream in the form of a card.
Expand the cards, which give the target warehouse, baseline line, documents, questions examined by the editor-in-chief, links to official information, and the scope of "Pr can be submitted without merging, without publish". The supervisor is giving Codex a statement of work that can be performed independently.
Two things need to be clear about this transfer: what kind of input the implementer gets and what step it can take this time. The review could serve as a basis for modifying technical details, such as clearance, and Codex would also need to review official documents and current warehouses to confirm the recommendation.
The local environment is also connected. I looked through the open source of LobeHub: in CLI connection, for example, lh connect connect to the device gateway, and start the corresponding Agent running process on this machine after receiving an execution request. The request contains the Agent type, working directory, prompt and subject identifiers, which allow cloud assignments to be placed on specific machines and directories.
Device Connection: Github.com/lobehub/lob...
So, when accessing Codex, Claude Code, you need to ensure that the CLI of your own machine is functional and then access the equipment via a desktop end or CLI connector to configure the corresponding environment and working directory for the executive member. The ability to read and write files, to run commands and to push codes also depends on the limitations on the implementation of the machine 's files permission, CLI, and the login and authorization status of Git and GitHub.
In my collaboration rules, the implementer has to read the warehouse's AGENTS.md, check the status status, the current branch and the baseline group; there are no changes to keep, and many people are separated from each other when writing the code at the same time, without being able to isolate. Allowing document modification, allowing push, allowing PR, allowing consolidation and publish, respectively. These rules are subject to compliance by the implementers, and physical access restrictions remain controlled by the local environment and service provider permission.
At the time of delivery, I asked to bring back the file to change summary, to actually run the commands and results, to link the committee and the PR. Reviewer wants to review the specific version; if a new version is submitted later, the affected part needs to be examined. No running tests, unverified pages.
Acceptance provided by the team is another acceptance check method: • Dismantling the demand into a check item, accompanied by a screenshot of the actual product, a video and a log, which is summarized in a report that allows for acceptance or amendment on a case-by-case basis.
In my cluster rules this time, I asked Reviewer for an independent review of specific code versions. Where acceptance check page representation is required, this evidence can also be included in the screens and screens.
Acceptance Open Source Address: Github.com/lobehub/acc...
And the review also showed me that the biggest problem with the website is the timeliness of content.
I've got new news on the Cordex website, and I'm too busy to synchronize it in time, so I'm going to slow down. This time, the existing problems have been corrected, the latter updated, and there is a need for continuous follow-up.
So I added an automatic inspection and turned it into a regular task.
After the supervisor analyses the needs, the content is compared to the content editor-in-chief and the time check is assigned to Lobe's assistant. Follow-up allows for the initiation of inspections at the set time and reduces the number of times I follow up manually.
It's not just about time. The status of the mission, the source of data, the target, the scope of the inspection, the content of the delivery and the scope of the authorization are itemized to provide a clear basis and boundaries for subsequent implementation.
The daily inspection was established as an independent T-2 Task, which is scheduled to be carried out at 9 a.m. Beijing time. Records of the first and second rounds of operations are available on the mission page, and cross-reference comments from the supervisor, Lobe assistant and the content editor-in-chief remain below.
From the content editor's own page, you can also find the implementation topic of "Source: Tasks". Task carries the matter of continuous inspection, and each round of execution has its own subject record. Follow-up inspections still need to continue as planned after one topic has been filed.
This also explains when I directly appoint members and when I build a Task: the work that has been identified in the current group conversations can be handed over to the counterpart Agent by assigning cards; it is more appropriate to use an independent Task when, as with daily inspections, it is necessary to repeat the work of checking progress. If more reliance and review are to be managed later, I will also give priority to these tasks in the context of sustainable follow-up.
There are also concrete points for the context handover. This long report is stored in the content editor ' s Agent Documents, with links posted to the mission review; code changes left in the warehouse and in the PR; the follow-up inspection is asked to follow up on the progress, unresolved items and report links in the review. This division of labour allows the organization to deliver:
There is also a real problem here: the editor-in-chief can't open the expected inspection father file, and the tool returns. It keeps its own Agent Documents for the time being and returns the link and cause of obstruction to the mission review; the progress and index of the filed documents are not expected to be updated.
The supervisor then requested that the next round first save the progress of the inspection, retrace the trail and unsolved items with a mission review and then try to establish the available archive location. This enables the work record to be captured, but the other Agent actually needs to open the check if he can read the report. The documents are stored, the links are passed, and those who take over read them, are the three points that require separate confirmation.
Similar details can be found in the review configuration. In the record, Lobe's assistant tries to set up an independent Verify, write it and ask again to show not compromised, and then configure the task Review to set autoRetry=true, maxites=2. These are configuration handover records, and the first round does not have an independent decision, and therefore cannot be considered as having been reviewed.
In the case of PR being knocked back, dependent on change or failed implementation, I have agreed in the collaboration convention to deal with: leaving the cause and evidence of failure in the original mission, providing a new version after repair and then reviewing it as a new company; re-checking the affected downstream work when upstream findings change; and, if permission is missing or needs to be expanded, report obstruction before the supervisor coordinates or comes back to me for confirmation.
LobeHub also supports a message event trigger: the selection is based on the rules of channel scope, keyword, etc., and then the model combines Agent ' s duties to determine whether intervention is required. For example, there was feedback from people in the group on a defect that could trigger follow-up when conditions were met.
It also makes me feel that “proprio motu” needs to be clear about the conditions: when to check, where to intervene, where to deal with, and where to come back for confirmation. These will be matched with evidence left over from each round of execution before continuous follow-up can be given to it.
In addition to following up on the official updates, I would like to add some practical examples to the site, so let it look for useful Codex on X.
It retrieves and collates a number of cases and gives reasons for recommendation, one by one, to facilitate my judgement on what merits further study and collation.
It also looked at a question I mentioned a long time ago and responded in detail.
What is useful to me is that both the basis of judgement and the follow-up recommendations are left behind. And then I'll deal with this issue, and I'll keep track of the progress, and it'll be easier to find it back.
In addition to website maintenance and problem-checking, I recently made a selection study of short video requirements, which was also given to Lobe.
I asked it to analyze the AI tools on Douyin, the AI efficiency and the AI programming, and see what these videos could do for example, and then to combine the comment area and sort out the real needs of users.
After receiving the assignment, Lobe splits the research into two lines, creating a sub-Associate, retrieving the AI tool and efficiency content in parallel, and the AI programming content.
During the execution, the right panel shows the tasks currently running and the use of their resources. It also allows me to see the CPU, memory and disk usage of local computers, so I know how the missions run and how the computer loads.
If you want to see concrete progress, click an opening assistant, you can see its implementation and output.
After the study of the two lines was completed, Lobe summarized the results into an analytical report comparing account volume and video data, as well as analysing the content depth, titles and comments of each video.
On the basis of this information, it further combusts the type of content per video, the factors that may drive its dissemination, the practices that deserve to be drawn upon, and the demand signals revealed in the comment area, then collates the selection strategy, the recommended video structure and the pits that need to be avoided, and brings the analysis to subsequent content creation.
In addition to this analysis, the recommendations have been consolidated into a field manual, which offers concrete approaches ranging from the selection of topics that can be launched with a cold start to the account, to script writing, to the filming of different types of videos and their follow-up. Thus, the preceding cross-reference analysis is not just for my information, but can then be used to organize selection and filming.
The entire mission ran for about an hour, from the search analysis of two lines to the synthesis of reports and the operational manual. What was finally in my hands was both the results of the analysis and what next step could do.
The entrance to the mission can also be placed in a regular chat tool, such as WeChat, which I have access to.
I got it in WeChat to help me find a good case of using popus 5.5 last week. Upon receipt of demand, it assigns sub-agents and starts searching. In this way, an issue to be studied can be dealt with in WeChat.
In practice, I feel more deeply that after the completion of the first step, there is an opportunity to move on.
The issues identified in the website review were subject to actual modifications and PR; the inspection was continued because of concerns that the content was outdated; and the short video study was completed with the preparation of a manual that could be used to organize selection and filming.
The individual Agent is stronger, trapped in a single conversation, and the work is cut off from the dialogue boundary. With the assignment and tasking of the supervisor, the product of the previous step became an input of next step, giving the task an opportunity to roll down on its own.
Turning back, I was the first to set up the Agent architecture, actually stuck in the same place.
Agent, who collects hot spots, throws the results to the team, waits for confirmation of the selection, the whole line stops when people are busy.
Without incident-driven and autonomous decision-making, people are bottlenecks.
Now that managers are assigned and tasked, I can focus more on goals and outcomes: what is worth updating, what is appropriate for me, and whether delivery meets the requirements.
Of course, these judgments have to be made by themselves. Before the start of the mission, the objectives, scope and acceptance check required clarity; the results were returned and specific modifications were made following an evidentiary examination.
The initiative of Super-agent is particularly important in this system.
When to check, where to intervene, where to proceed and where to return for confirmation.
The conditions are unclear and the initiative is easily disruptive; it is clear that each round of implementation leaves evidence before continuous follow-up can be given to it.
To be honest, it took me a while to understand Agent.
At first it was thought that using Agent was replacing itself.
Then I realized it wasn't at all.
Those repeated, information-driven missions can indeed be handed over. The rest is more my part: the value is not worth it, the result is not done, where next step goes.
Super-agent helped me return my time and let me focus on really important decisions.
LobeHub, who has been developing LobeHub himself with Agent, should also be called upon.
Agent was added to the capacity to facilitate follow-up of the Agent division of labour.
If you run your own process and let it run your own way faster, it's the positive cycle that's what it's supposed to be.
I'm getting the feeling that the core ability to use Agent is probably not "writing prompt," it's to decipher the target, to understand acceptance criteria, to drive it.
This is essentially project management.
It's just, you run this team, it's all AI.
Are you picking up your own Agent workflow? The comment section is welcome to talk about your practice, or to say a few words to let me know that this is helpful.
Auto-fetched and translated by AI Atlas. All rights belong to the original author.