编排workflow 要小心这点 报错信息 ● Dynamic workflow “Corrected fully-parallel six-stage rebrand mapping with fine-grained total stages” failed: WorkflowAgentCapError: Workflow agent() call cap reached (1000). This usually means a loop using budget.remaining() never terminates because no token budget was set — remaining() returns Infinity when budget.total is null. Add a hard iteration cap to the loop, or pass a token budget. at V (B:/~BUN/root/src/entrypoints/cli.js:3980:1437) at (B:/~BUN/root/src/entrypoints/cli.js:3984:6113) at processTicksAndRejections (native:7:39) · 24m 34s 2 个帖子 - 2 位参与者 阅读完整话题
本人是CS相关专业的本科生，想问问有哪些工具/工作流的编排可以全自动从idea获取一直到最后的整个项目完成都是全自动的？之前看到ai可以完成能发icml的论文，自己也想试试，发一些workshop之类的 4 个帖子 - 4 位参与者 阅读完整话题
太久没上论坛，感觉发生了翻天覆地的变化。最近在给公司做Dify企业应用开发，学到了很多新东西，给佬们开开眼界。 起因是要设计图文混排的工作流（workflow），因为是后端异步调用dify，所以不用担心耗时的问题。因此最初我的设计是先让LLM输出完整的内容，然后再让另一个LLM理解这些内容，输出一个对象数组，每个对象包含文生图提示词以及图片在内容中的位置（这里采用的方案是按\n\n分割内容，然后计算图片在分割数组中的索引），循环调用文生图工具，将图片上传oss后将oss地址插入到内容中，最后返回。 最近提了个新需求，要求给dify的对话流（chatflow）开发图文混答，由于这次是文本图片采用流式输出，就必须考虑耗时的问题了。然而市面上的教程清一色的都是构建知识库，然后在知识库文档中引入图片地址，这样AI检索到图片地址就能完整的输出。但是这种方式非常依赖知识库，而我们的场景主要是医疗领域（产品很多地方借鉴了阿福，只不过我们是针对私域的，而非公众通用），知识库数量庞大，并且维护困难。 就在我一筹莫展之际，我找到了这篇文章： baijiahao.baidu.com 苹果研究团队：AI实现图文理解与生成统一框架能力提升突破 通过AI解读和理解之后，给出方案为先规划后生成，并且用两个迭代节点并行生成文字和图片，通过代码调度控制输出的节奏。比如：规划LLM给出一个对象数组，大致如下 [ { "id": "text_1", "content": "第一板块的概括内容", "depends": [], "index": 0 }, { "id": "image_1", "content": "基于[text_1]的内容，生成图片：高科技宣传图，蓝色主色，未来风", "depends": ["text_1"], "index": 1 }, { "id": "text_2", "content": "第二板块的概括内容", "depends": ["image_2"], "index": 2 } ] 完成生成的内容会写入队列（Redis），每次输出前都会从完成队列中读取所有未消费的项，判断当前项是否有依赖，依赖项是否完成，是否消费，同时依赖项的依赖项是否完成以及是否消费（递归），满足条件的按照index排序，确保输出顺序正确，最后拼接和输出。当然，这里我只是简单概括，实际逻辑要更复杂，大概是这么个意思。 测试流程效果: 现阶段的问题还是出现在循环里的文字生成LLM的提示词不够完善，由于架构的弊端，AI每次循环生成的段落可能重复，加上有一些特殊的业务需求，模型不给力就靠蒙，只能用qwen3.5plus才能勉强满足要求。 不过工程问题都好解决，优化一下速度还是能够落地的。 1 个帖子 - 1 位参与者 阅读完整话题
感谢L站，高中生拿下广东省粤港澳学生科创大赛智能体冠军 跟着站内佬友学了很多agent编排的干货 这下真的是 学AI 上L站了 还剪了一个两分多钟的冠军速通第一视角vlog，发在视频号了 channels.weixin.qq.com 视频号 18 个帖子 - 18 位参与者 阅读完整话题
最近使用有时会碰到这个 使用最新的ultracode模式时编排总是卡在最后一个agent 之前的几百m token全浪费了！ 这个可以解决吗 还是说是any本身的问题 3 个帖子 - 2 位参与者 阅读完整话题
在 Anthropic 随 Opus 4.8 推出 Claude Code 动态工作流与 ultracode 模式仅数小时后，开源框架 OMO 团队在 X 上发起猛烈攻势，公开指责 Anthropic 像素级抄袭了其多模型编排架构。 OMO 作为 16.7 万星开源终端 Agent 项目 OpenCode 官方认定的 No.1 插件，由 23 岁韩国黑客 Q 开发，并由运营团队 Sisyphus Labs 宣发，目前已斩获 6 万星，在开发者社区极具声量。 这场风波直接撕开了大厂「先封杀、后吸收」的掠夺路径。今年 1 月，Q 在 OMO 中推出了用于多模型动态编排的 ultrawork 工作流以及负责合并审查的协调大脑 atlas。由于这套编排机制在运行多智能体递归循环时会吞噬天量 Token，被 OpenCode 联合创始人 Dax Raad 吐槽为「Token 燃烧器」，高能耗调用直接促使 Anthropic 在 4 月份痛下杀手，强行封禁了第三方客户端使用订阅额度的通道。 仅仅三个月后，Anthropic 官方就将这套已被开源验证的动态编排逻辑收编，化身为自家 Claude Code 的闭源收费主打功能。 除了死磕 Anthropic，OMO 团队与 FactoryAI 在今年 2 月也存在旧怨。FactoryAI 此前高调宣传的 Missions 多天自主任务流，被指直接搬运了 OMO 的三层 Agent 架构：OMO 的规划器 Prometheus 变成了 Factory 的计划审批流，协调大脑 Atlas 被改名包装为 orchestrator Droid，执行器 Sisyphus Junior 变成了 Worker Droid，甚至连原装的技能过滤机制都被简化挪用。 面对 OMO 团队晒出的历史开发记录，以及要求大厂公开致谢并承认原创贡献的喊话，两家大厂至今装聋作哑。开源团队则继续在推特上进行多维度反击。 一方面，Sisyphus Labs 强调 OMO 框架是完全模型无关的，用户不需要高昂的官方配额，用本地或便宜的 GPT、Gemini 甚至 Kimi 模型同样能跑起 ultrawork 工作流，并透露正在开发基于 GPT-5.5 的 Codex 适配版本。 另一方面，Q 亲身试用后对新模型打出了毒舌评价，认为新模型不过是一款不错的 GPT-5.5 中量级模型。此外，Q 还反手给出了一个幽默的嘲讽：他直接用 Anthropic 的官方新工具，命令它把 OMO 原创的编排逻辑重写一遍，做成一个可以反向挂载到 Claude Code 上的兼容插件。Q 调侃道，这就当是帮大厂做个兼容实验，毕竟开源团队的创意被直接拿走，大家早都习以为常了。 2 个帖子 - 2 位参与者 阅读完整话题
大家好，我最近做了一个开源工具：Gold Band 。 github 地址： https://github.com/diodeme/Gold-Band 技术栈：Rust + React + Tauri 2 + Agent Client Protocol 名字 Gold Band 来自“金箍”的意象。我的理解是，AI 本身已经足够强，但在真实工程任务里，问题往往不是“让它做事”，而是让它在长时间、多步骤、有回环的任务里持续沿着正确方向做事。Gold Band 想做的就是给 Agent 加一层工程化的约束和编排。 做这个工具的初衷也是为了方便自用，在过往我的 AI CODING 历程中，碰到过一些问题： 长程任务虽然存在 subagent 、agent team 等分治协作策略，但对于主会话的 orchestrator 来说，一旦任务周期过长，还是会出现编排错误或者 orchestrator 直接自己下场干活的问题。 使用 ralph loop 等工具，但存在 agent 又当运动员又当裁判的问题，缺少交叉性验证，无法保证最后 completed 的输出到底是否可靠。 skill 、constitution 、mcp 等未形成统一加载标准，各个 agent 自治规范，维护起来比较麻烦 claude code 的 subagent 无法继承会话的 skill 列表，只能由主 agent 告知或提前定义好，所以 subagent 的能力受限（这一条问题在最新版本已经解决了，测试版本为 v2.1.153 ，但在当时让我觉得与其等待 agent 厂商不知何时的修复，不如自己做外挂解决好了） 同时我也一直相信，AI 应用最好的方式，就是用工程化手段降低 AI 的不稳定性，发挥 AI 的创造性，所以基于上面的问题和理念，我想制作一个 可以使用工程化手段稳定 AI 工作流且统一管理 Agent 所需的上下文 的工具，或者再简单一点，可以理解为 一个本地 Agent 工作流版的 Dify ，这个工具就是现在的 Gold Band 。 功能介绍 任务编排 用户可在创建任务时，为任务指定具体的工作流。 工作流可直接在画布中可视化创建或复用现有模板。 Gold Band 系统也内置了一套工作流。 一些概念 节点 ：每个节点代表一次 Agent 执行，用户可以在 agent 管理 中进行 Agent 配置，理论上支持 ACP 的 agent 类型都可以调起，但是由于目前每个 agent 对于 ACP 的支持程度各异，所以我们只会在完整测试通过后才加入到支持列表中，目前 Claude Code 是已经验证通过了的。 角色 ：每个节点内置的角色，会追加到系统提示中（目前有部分 ACP Agent 不支持追加 system prompt ，则会追加到 user prompt 中（正在探索是否有更好的方式）） ，用户可在 上下文管理 中进行角色的编辑，Gold Band 内置了一套角色，参考本文后续的介绍。 权限模式 ：系统在加载 ACP 时握手阶段获取到的 ACP Agent 支持的权限模式列表，用户可以在节点设置中进行选定。 结果判定 ：关于如何决定节点的 分支走向 。Gold Band 提供两种方式：1.人工 check ，人工点击成功或者失败作为该节点的结果，适用于方案节点等需要人工审核的场景。 2.AI 输出验证，指定 Agent 输出的 DSL 和结果判定表达式，系统自动根据表达式判断节点结果。比如： //DSL { "reason": "String", "result": "boolean" } //表达式 $.result == true 边 ：画布中点击边，即可对边进行修改，选中目标和 session 方式（ new 代表新建 session ，continue 代表在原 session 上继续） 内置工作流 ：Gold Band 目前内置的工作流如下： 比较重点的是审查和测试不通过会回环到开发节点，用 continue 的方式进行修复。 验收节点会验证需求是否真的完成了，未完成会输出报告并进入下一轮 round 。 验收后会有 clean 节点对过程产物进行清理并持久化到项目目录下。 用户也可以完全不用该内置工作流，自行新增偏好的工作流。 任务执行 用户在任务目录下点击新增 run 即可对该任务发起一次执行 用户可以对一个需求发起任意多次执行 发起执行后，用户可以在 run 详情中观察每一轮 round 具体的执行情况 一些概念 attempt ：节点对回环为一次 attempt ，比如 测试-failure->开发 算一次 attempt ，工作流中可以限制运行时每个节点对 attempt 的最大次数，超过次数则拒绝。 round ：节点可指定结束状态开启一轮新的 round ，新的 round 会从头执行工作流，并在系统提示中告知 agent 当前轮次和上轮产物目录，工作流中可以限制运行时 round 的最大次数，超过次数则拒绝。 产物目录 ：过程产物全部放在~.gold-band\projects<project-path>下面 一个实际的产物目录如下 //artifacts ~\.gold-band\projects\D--Projects-code-ai-Gold-Band\tasks\task-001\runs\run-001\rounds\round-001\nodes\开发\attempt-001\artifacts //attachments ~\.gold-band\projects\D--Projects-code-ai-Gold-Band\tasks\task-001\runs\run-001\rounds\round-001\nodes\开发\attempt-001\attachments artifact : 有明确输出要求的节点，系统会自动把节点的输出放置于 artifact 下面，参考结果判定这一概念中的 AI 输出验证。 attachments ：节点可自由输出文件、报告的目录，比如测试报告之类的都在这里 会话观测 节点运行中，用户可以在此观察会话实时运行状态，当然也可以在会话结束后进入对应的 cli 查看。 节点执行完后，用户依然可以继续在该窗口对话，会使用 continue 方式继续调用 agent 。 continue 方式 一些概念 系统提示 ：展示 Gold Band 运行时追加的 system prompt 原始帧 ：ACP 会话的原始流，用于问题排查 Agent 管理 使用 ACP 方式拉起 agent 进行会话，可在此页面进行配置和环境诊断 虽然理论上支持所有 ACP 兼容 agent ，但是出于测试严谨性，现阶段仅推荐先用 claude code 上下文管理 可在此进行上下文管理，目前仅支持角色管理，后续会考虑扩展 skills 、rules 等能力 内置角色无法修改、删除，但可以修改后另存为自定义角色 设置 当前设置项包括： 中 / 英文语言切换 主题切换 字体切换 更新机制 本地 Claude Code 开关 本地 Claude 开关为临时方案，后续可能会优化。开启时使用本地 Claude Code 可执行文件，关闭时 Claude Code ACP 组件会拉取 Claude Code SDK 中携带的 claude.exe 。 后续安排 目前 Gold Band 其实依旧处于 开发者预览阶段 ，目前为止的版本虽核心链路已经能够跑通，但是产品体验上就本人看来依然还有诸多需要优化的点。所以本次推广， 第一是希望 mvp 版本也能先帮助到和我有一样问题的朋友们，大家可以看看方向是否值得继续打磨，欢迎提 issue \pr 或直接喷我哪里不好用。 第二是向大家同步下后面的开发计划，后续除了我之外，也会有一个很小的团队兼职参与维护。当前阶段我们会优先处理影响核心使用路径的问题，并根据真实反馈补充事项或调整后续优先级。目前暂定的待办项如下： 高优先级处理 多 agent 支持，优先测试跑通 codex\cursor\gemini cli\opencode 的集成，视情况增加更多 agent 。 系统通知能力，agent 请求权限、工作流报错时进行系统通知，设置中可选关闭。 支持自适应工作流编排与并发执行： 支持节点级并发：一个节点可以同时分发到多个后续节点，并行处理不同子任务；可在实验室功能中配置最大并行数。 支持需求级并发：一次导入多个需求后，可让多个需求复用同一套工作流并行执行；可在实验室功能中配置需求并行数。 支持 AI 动态路由：工作流执行过程中，由 AI 根据当前任务目标、上下文和中间结果，动态决定下一步应进入哪些节点、拆分哪些子任务，以及是否并行执行。 中优先级处理 增加对 skill 的支持与管理 增加对 mcp 的支持与管理 优化 ACP 会话观测窗口的性能表现，样式优化，使用体验，修复一些已知问题 增加指标统计能力，包括会话用时、token 消耗量等，提供数据看板。校对目前会话用时的准确性。 写在最后 Gold Band 目前还处在很早期的阶段，肯定还有不少粗糙、不合理甚至跑不通的地方。但这个项目不是为了蹭概念做出来的，而是我自己在长期使用 AI Coding 时确实遇到了一些问题，才一步步把它做成了现在这个 MVP 。 我个人一直觉得，AI Agent 本身很强，但真正要在复杂任务里稳定发挥作用，还是需要工程化的约束、编排、验证和观测。Gold Band 想做的事情，就是把这些能力尽量整理成一个本地可用、可配置、可持续演进的工具。 如果你也对这个方向感兴趣，欢迎试用、提 issue 、提建议，或者直接指出哪里设计得不合理。 感谢各位看到这里，也欢迎大家轻喷重喷。只要问题真实，对我来说都很有帮助。
最近mimo不是白送了很多token吗 以及deepseek降价，但是纯使用国产模式来的话 在复杂问题时国产模型可能不尽人意，我有一个想法，如下图： 逻辑大概就是：让Claude Code Opus 4.6来指挥小米的MIMO模型来干活，可以加一个双向通信，如果说子代理遇到了不懂的事情，不要让他瞎改，让他停下来去问主代理，同时多个子代理去开发的时候，是开新的Git分支，通过提PR code review的情况下交流。这样不会改同一个文件被覆盖。聪明的模型做规划，弱的模型做实现。 如果说Claude Code给到的方案足够详细，以及mimo接到开发任务之前，先给方案，让Codeclaude进行方案评估，再开工，在这两个前提下，是不是能够做到？ 以国产大模型的价格达到国外模型的质量呢，可以大大利用起来这些低价的国内大模型。 大大提升开发效率，同时，成本大大降低，但是效果与纯cc差别不大。 4 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 Wjinlei/project-manager: 本地项目管理，可对项目一键进行启动停止，配置切换，流程编排等，纯AI开发 求PR，这个项目采用纯AI开发，主要是为了解决本地多项目管理混乱的问题。 项目目前还很基础，还有很多功能没实现（主要我token不足，思维也很有限，哈哈哈），因此希望能和更多人一起完善这个项目，欢迎各位佬友发挥你的思路，增加各种实用功能或者修复任何已知或未知BUG，提交PR，爱你呦！！ 哦对了，说明一下，这个项目是我纯兴趣搞的，不存在任何盈利目的。 1 个帖子 - 1 位参与者 阅读完整话题
如题，之前看过风佬的ccg-workflow项目不错，可惜没有 Claude支持 我目前想的写个skills让两个ai交流（codex和Antigravity分别将要和对方讨论的话术、相关聊天记录以本地md文件方式交流），效率问题会低很多，还不如手动 不知道佬们有没有啥可行方案 1 个帖子 - 1 位参与者 阅读完整话题
需求就是给你一个任务，主ai负责拆解为子任务，然后根据子任务自动使用不同的ai协同或不同model。liner或zed没用明白 4 个帖子 - 4 位参与者 阅读完整话题
写在前面： 一年前，我在站外瞭望（搜某个github项目的时候被引到此宝地），半年前我也成了佬友，半年多的时间我只在评论区溜达，这是我的第一篇主题贴 恳请大佬指点 项目简述： “中年iT，依然拥抱全新的世界”，年龄不代表资历 Ai行业是一个新的领域，经过在Linux.do的学习（划水、摸鱼）和熏陶，最近自己动手做了一个多模型协同编排（planner + executor）的小项目，雏形可执行简单任务，尚未成熟。这个跟很多佬都有过零星的互动，有的佬咨询在openclaw如何实现多agent协同，有的佬在寻找有哪些好用的多agent方案…这个项目，正是回应这些需求的一次实践。 简单说： 强模型（云端）负责规划、拆解、决策、复盘； "轻量/本地"模型负责文件、命令、搜索、数据处理等执行； 支持长任务、多步骤、工具链、事件流、持久化； 已跑通 MVP，能稳定执行复杂工作流，TypeScript 实现，跨平台。 多agent在开发者眼中不是新鲜事物，也有很多种协同、协调的方案，那么一般用户是否也可以共享这样的科技？只要配置好强模型和执行模型，就可以节省强模型token（经济层考虑），如果执行模型是本地模型，就能一定程度的保护隐私（安全性考虑），本地模型工作又有强模型的指导、监督，从而提升效率和可靠性。 从目前发展看，"任务编排和蜂群协作"应该有一定的发展前景。（Ai行业日新月异，仅为当前展望观点） 咨询重点： 我个人精力（主要是能力）有限，不确定是否适合在站内发起"开源/科研"实践类共建（看github某些项目成员3、40人的团队，我Linux.do也人才济济，组队一定更强）： 1、这类项目在本站是否可行？有没有先例？ 2、有没有有组织经验的大佬愿意牵头？我可以无偿转让所有前期代码、文档、创意，不保留任何权属。 3、学生群体是否愿意参与这类实践？能否作为"科研 / 社会"实践项目？ 我不追求署名、不商业化、只想把这个方向落地，给社区、社会做点贡献，若有荣誉，也应该归于 linux.do 。 想听听大家真实看法：可行吗？风险在哪？有没有更好的方式？ 感谢各位耐心看完，期待大家的宝贵意见和建议。 3 个帖子 - 3 位参与者 阅读完整话题
最近Claude code新出了一个ultrawork命令，类似于在执行你的命令之前先编排好工作流，用js写成一个可复用的workflow，以mjs的形式存在，然后调用multiagent按workflow执行。 看了下和omo的ultrawork挺类似的，应该还能通过自定义这个mjs，调用codex，antigravity此类的。 如何调用codex，antigravity此类的。参考codex官方推出的codex-plugin-cc，修改下这个mjs文件即可。 3 个帖子 - 3 位参与者 阅读完整话题
问下Ai应用开发中agent编排问题,大概知道编排的4种模式,总管,工作流,交接,Council 议会,但是这几种如何去选择合适的呢？比如OA选用工作流？ 3 个帖子 - 3 位参与者 阅读完整话题
我现在看到大家可能用很多框架, skills, 或者叫编排器. harness等等, 名词太多 但肯定只有一个目的, 就是希望能全自动从头到尾开发减少人的介入 但我现在有个疑惑, 就我本人经验, 任何开发项目都不可能开始就把prd写的完整且没有漏洞, 不包含错误 在这种前提下, 从头到尾开发不介入, 真的合适吗 7 个帖子 - 7 位参与者 阅读完整话题
大家好，新人入坑第 15 天，第一次发帖。 最近在折腾 AI 工具，发现坑挺深的——模型越来越多，能力差距也大，API 调用方式各有讲究，反而不知道怎么选、怎么组合了。感觉自己在瞎用，想来请教各位佬是怎么搭自己的工具链的。 纯粹来学习的，欢迎佬们分享工具链、经验，感谢 4 个帖子 - 4 位参与者 阅读完整话题
大家有没有觉得 vibe coding 的过程随机性太强了，个人小项目搞一搞问题不大，但大一点的项目感觉就很难支撑了。 有没有类似 Jira 的 Agent 任务编排工具，调研了几个都感觉很简陋
本人前几天开了一台机器，机器上部署了cpa和newapi，然后给newapi接了同一个编排里的cpa做上游，cpa里是纯codex号池。 目前已经跑通了，给朋友也能用，但是我通过反复的试验和观察后台，发现朋友用的ccswitch接codex，基本都能缓存命中。 但是我自己使用的是ccswitch接claudecode，则每次输入都只显示缓存读一个很固定的且远小于输入token的量（比如每次输入十万+，显示缓存读一万+，无论是在newapi的使用日志上还是在ccswitch的统计计费上，都是一样的结果，导致统计使用的费用很高。 我也尝试过使用codex来调用newapi，发现newapi和ccs上都显示的很高的缓存命中。 然后我还试过给机器的也就是newapi上游的cpa端口打开，直接用claudecode去接cpa的api，ccs里面显示回到了很高的缓存命中。 也逛了下站里的帖子和newapi的issue，但是还是不太清楚怎么改善这个问题。 看起来像是newapi的问题，因为我直接接上游cpa是没问题的，然后还可能只是统计错误实际是读缓存的了？但是ccs里也跟着显示基本没缓存命中，所以就有点搞不懂了，想试试找佬友们支个招，需要更多信息的话我可以稍后传上来。 7 个帖子 - 5 位参与者 阅读完整话题
求教，如何让多个agent协作处理任务时，任务如何拆分比较合理？ 3 个帖子 - 3 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 项目链接： GitHub - dalamudx/ReleaseTracker: A lightweight, configurable release tracking and update orchestration tool. 一款轻量级、可配置的容器版本追踪和管理软件 。 · GitHub 本项目核心功能是支持将版本追踪、发布说明进行聚合，然后对不同部署形式的容器统一进行版本更新管理。 支持对GitHub、GitLab（含自托管）、Gitea、Helm Chart、Docker Hub、GHCR、私有 OCI Registry等仓库或容器版本的追踪。 支持对podman、docker、compose容器组、helm release、kubernetes、portainer的接入，以及对应部署的更新管理。 通知目前只支持webhook，后续会看情况进行扩展 开发这个项目主要是出自我自己的需求，统一对容器化的服务进行版本更新管理，然后加入了对分支、发布说明这块的处理，不过目前做的还不是很好，还有待改进。 当然，这个项目也不像watchtower那样，打个标签就能用，专门精细化了版本控制这块并有丰富的自定义功能。 更详细的功能说明可以参考下wiki： ReleaseTracker Wiki - ReleaseTracker 佬如果有需求可以提issue，然后功能合适的话，会排期进行开发 3 个帖子 - 3 位参与者 阅读完整话题