也不能说是bug吧，只能说开发出来的东西能用。 稍微中型点的就像东拼西凑的一样，很难有很少的体验 需要多次打磨，也不知道是不是我要求太高了 以前ai都无法正常一个正常的应用，现在可以但是还觉得不够 各种框架 技能都试过了 但是总感觉不够好 我是只用codexapp了 9 个帖子 - 8 位参与者 阅读完整话题
自己部署了一版Nestjs的学习手册，方便学习，分享给佬友们。 内容简介：学习 Nest 全部功能，并且会顺带把 mysql、mongodb、redis、rabbitmq、nacos 等后端中间件学一遍，也会学习 pm2、docker、docker compose 等部署方案，并做几个综合的全栈项目。 地址： https://nest-docs.elias.ccwu.cc/ 13 个帖子 - 5 位参与者 阅读完整话题
HY-World 2.0 是一个面向 世界生成 和 世界重建 的多模态世界模型框架。它接受多种输入模态——文本、单视图图像、多视图图像和视频——并生成3D世界表示（网格 / 3D高斯点云）。 暂时只放出了WorldMirror部分，模型不大，1.2B参数，如图5090跑32帧差不多占满30g显存 4 个帖子 - 3 位参与者 阅读完整话题
各位佬友好，最近在研究多agents协作的机制，并且在尝试在目前的业务领域进行应用（可见本人profile）。目前发现最大的一个问题是除非当前协作任务到达上下文，否则所有的agent都会如同得了羊癫疯一般埋头跑，任务推进效果也不尽人意。 这就引发了本人对于agent协作的刹车机制的构建，请问各位佬能否分享一下相关的经历或者有趣的解决方案。 1 个帖子 - 1 位参与者 阅读完整话题
各位佬友,公司最近想把几个老业务系统全部重做,将之前的多个系统作为以业务为驱动的一个大系统,每个系统可以独立部署,但是前端方面我担心由于页面和代码量的过多,会严重影响性能,请问一下各位,有没有合适的实现方案,技术栈为vue3+elements plus ui框架,微前端会是一个比较好的解决方案吗 3 个帖子 - 2 位参与者 阅读完整话题
一开始由Gemini完成前端样式框架开发，后面由GPT完成业务部分 使用的技术栈是:Nuxt 4、Nitro、Prisma 、MySQL 现在也还在打磨中，欢迎各位佬提意见 接下来的规划：邮件发信（用于评论通知），评论的IP地址，评论内容自动审核 演示地址： https://test.789dl.cn/ 图片： 20 个帖子 - 12 位参与者 阅读完整话题
卡内基梅隆大学计算机科学系教授 Dimitrios Skarlatos（CEO）和 Zhihao Jia（CTO）创办的 AI 基础设施公司 Lithos AI 开源了 Agent 服务框架 Motus，Apache 2.0 许可证。团队由 CMU 和斯坦福研究人员组成，成员有 AWS、谷歌、Meta 和英伟达的生产基础设施经验。 Motus 的核心思路：不同任务适合不同模型，与其始终用最贵的前沿模型跑所有步骤，不如让系统从生产运行的轨迹中学习，自动把不同子任务路由到最合适的模型。当前 Agent 部署后是静态的，提示框架、模型和上下文策略固定不变，Motus 则从每次运行中提取任务成功率、延迟和成本信号，持续优化。 据 Lithos AI 官网数据，在 SWE-bench Verified 上，Motus 多模型编排达到 79% 准确率，高于 Claude Opus 4.6 的 75.8% 和 GPT-5.3-Codex 的 72.6%，成本不到单用 Opus 的一半。在 Terminal-Bench 2.0 上，准确率从 Opus 的 64% 提至 80.1%，成本同样约减半。框架还会根据具体工作负载调整上下文记忆策略，并自动检测可并行执行的步骤来降低延迟。 github.com GitHub - lithos-ai/motus: The open-source agent-serving project The open-source agent-serving project 5 个帖子 - 4 位参与者 阅读完整话题
我最近这个需求，在测试的身上耽误了 将近半个月时间，本来两个人1个月的工作量 我3-4天就写完了。有没有谁已经把 PRD → 设计 → 编码 → 多层测试 → bug 清单 → 修复代码 这条链路跑通了？有的话，能推荐推荐么，不想重复造轮子了. 它可以从接到需求，就能做任务分析拆解(比如使用多个角色讨论)，得到一个开发任务清单，进行代码开发，review代码，审查潜在bug，最后基于 PRD、代码实现、接口定义和业务规则，做功能测试，接口测试，能自己按照业务场景去模拟数据调用，发现bug，进入修复阶段，如上反复。最终完成开发任务。 原来帖子被人举报了，因为AI的问答没有使用图片，so换成了自我表述(不太会表达 hhhhh) 8 个帖子 - 5 位参与者 阅读完整话题
langchain4j spring-ai spring-ai-alibaba agentscope-java 不使用agent框架，使用原生openai、anthropic官方最小SDK自己搭建 点击以查看投票。 公司最近想开发一个harness类项目，我感觉harness工程定制化程度还挺高的，并没有一个很通用的标准，不知道这些agent框架能否满足，后面扩展会不会成为包袱，还是仅使用官方最小sdk来搭建，后续方便扩展？ 1 个帖子 - 1 位参与者 阅读完整话题
最近两个月一直在用 Superpowers，先说结论：它对我做需求分析、整理规范、拆设计文档和实施计划这部分帮助挺大，开发效率也确实提升了。 但我在公司真实项目里落地时，越来越明显地感觉到它的上限，想来请教一下大家，有没有更合适的 Agent 框架，或者成熟的工作流思路，甚至是值得借鉴来自研的方向。 我现在的实际工作流大概是这样的： 手动提前分析工程代码，整理一份适合公司的项目编码规范 把产品的 PRD/评审内容转成 markdown，交给 AI 阅读 让 AI 产出设计文档和实施计划 按编码规范开发功能 再用 code-review 做审查 问题主要出在后半段。 目前我的感受是： code review 不够稳定 有时候本来是对的代码，会被误判成 bug，改完反而错了；有时候又审不到真正的问题 TDD/单元测试 的帮助有限 现在更多只能验证代码能编、基础逻辑能跑，离“真正验证业务功能”还差很远 单元测试 接口测试 业务场景测试 / E2E / 集成测试 能根据 PRD 里的业务规则，自动分析场景、构造 mock/测试数据、调接口验证 最后输出 bug 清单、失败场景、回归结果 自动化程度还是不够 前面一个月开发速度确实快，但后面经常会有半个月被测试压力拖住，最后又回到大量手工测试，再通过对话让 AI 一点点修改 也就是说，编码提速了，但“测试和验收闭环”没有跟上 所以我现在真正想找的，不是单纯“更强的代码生成 Agent”，而是更接近下面这种能力的框架或方案： 能面向企业项目落地 能结合 PRD、项目规范、现有代码上下文工作 能从需求走到开发，再走到测试和验收 尤其是测试这一段，最好能覆盖接口级、业务场景级，而不是只停留在单元测试 即使做不到 100% 自动化，至少能把人工介入压到比较低 想请教大家几个问题： 现在有没有比较好用的 Agent 框架，适合这种“企业开发闭环”场景？ 有没有谁已经把 PRD → 设计 → 编码 → 多层测试 → bug 清单 这条链路跑通了？ 如果没有现成框架，有没有一些值得借鉴的架构思路，适合自己搭一套？ 对于 Java / 微服务 / 业务系统这类项目，大家一般怎么补“业务测试自动化”这一块？ 如果你也踩过 Superpowers 或类似方案的坑，欢迎分享一下你们后面是怎么优化的 我不是追求 100% 全自动，也知道这件事本身很难。 但我现在最想解决的问题是：不要只把“写代码”自动化，而是把“业务开发完成后的验证闭环”也尽量自动化。 如果有现成框架推荐、开源项目、实践经验，或者你们自己团队自研过类似流程，都很想交流。 项目类型：Java / Spring Boot / 微服务 (我感觉这种框架其实并不看重项目到底是什么技术实现的) 15 个帖子 - 12 位参与者 阅读完整话题
如题，getx 是 flutter 主流状态管理库之一，其作者jonataslaw 疑似销号删库跑路一条龙。目前 github 上该仓库页面已 404，pub 上该库页面还存在。 https://github.com/jonataslaw/getx Dart packages get | Flutter package Open screens/snackbars/dialogs without context, manage states and inject dependencies easily with GetX. 14 个帖子 - 7 位参与者 阅读完整话题
微软一直试图把 AI 塞进传统的 Word/Outlook 框架里。但现在的趋势（如 Claude ）证明，AI 可能需要一种全新的界面，而不是在老软件里加个侧边栏。 9 个帖子 - 7 位参与者 阅读完整话题
最近 GitHub 上各种 Agent 框架满天飞，老实说我已经有点审美疲劳了。大部分框架给你的就是一堆 API 零件，折腾半天环境，最后弄出来个只能按部就班执行固定 Prompt 的“智障助理”。 直到这两天，我深挖了一下 Hermes Agent 这个项目（目前 74.5k+ Stars），感觉头皮发麻。 这玩意儿根本不是个框架，它是一个 开箱即用、全天候挂机、带真实记忆闭环的 Daemon 进程 。 如果你手里有台吃灰的 VPS，或者你平时习惯用 CLI 和 Telegram 办公，这东西绝对值得你花十分钟了解一下。我总结了几个让我直呼卧槽的特性，大家品一品： 1. 终于有个长脑子的“记忆闭环”了 现在的 Agent 动不动就吹记忆，其实就是简单的 RAG 加上向量库。Hermes 狠的地方在于它 真能自己写 Skill 。 它会用 LLM 自动总结你跨会话的历史记录，提取经验生成具体的 Skill，下次遇到类似问题直接调用自我改进。配合 Honcho 做深度用户建模，你调教得越久，它就越像一个真正懂你业务流的赛博搭档。 2. 无缝切换底层模型（API 玩家狂喜） 这点对咱们手里攥着一堆中转 API Key 的人来说太友好了。 它 完全不绑定任何模型 。想用逆向的 Claude 4.6？中转站： https://kirouter.com/ 切！想接你自己的 OpenRouter/GLM/Kimi 甚至本地部署的 Ollama 节点？一句话 hermes model xxx 直接热切换，代码一行不用改。 数据、记忆、Skill 都在你本地的数据库里 ，外面的大模型对它来说只是个随时可插拔的“外包算力”。今天谁家的 API 便宜且聪明，就切给谁。 3. 极其极客的 TUI 终端与全平台打通 它的 UI 简直长在 Linux 玩家的审美上。 内置了一个功能极度完整的 TUI（终端用户界面），支持斜杠命令补全、多行编辑、流式输出、中断重定向。在终端里敲代码敲累了，直接唤出界面让它帮你干活，这沉浸感比 WebUI 强太多了。 不仅如此，起一个 Gateway 进程，它就能同时挂在 Telegram、Discord、Slack 上。你在地铁上用 TG 丢个语音备忘录给它，它在你的云端 VM 上跑完脚本，结果直接推送到你的 Discord 里，上下文完全贯通。 4. NLP 驱动的 Cron 与并行并发 真·无人值守： 内置了自然语言解析的 cron 调度器。不用去写恶心的 crontab 表达式，直接告诉它：“每天早上 9 点去抓一下昨天的服务器日志，总结一份报告发我 TG”，它就成了。 并发处理： 它可以自动 Fork 出隔离的子代理（Sub-agents）去跑并行工作流。通过 RPC 调用工具，把多步杂活（比如一边查邮件、一边跑 Python 脚本抓数据）同时扔进后台并发执行，最后主进程给你汇总。 5. 运行环境与开销（白嫖党的福音） 后端支持极其丰富：本地、Docker、SSH 就不说了。 它支持 Daytona 和 Modal 这种无服务器（Serverless）持久化。这意味着什么？意味着 空闲时休眠，0 占用 0 计费，用的时候瞬间唤醒 。 你随便丢在一台 $5 的低配小鸡上，或者拿个废旧安卓手机跑 Termux 都能完美承载。 最后说两句： 这项目是 MIT 协议开源的。我们一直想要的，不就是这样一个数据 100% 攥在自己手里、能力跟着我们一起成长、24 小时在线且不需要重度运维的“数字牛马”吗？ 不知道坛子里有没有老哥已经深度部署过这个项目的？ 我目前还在摸索它的子代理并发极限，大家平时如果用类似的项目（比如 OpenDevin、AutoGPT），都是用来跑什么自动化工作流的？欢迎在下面交流探讨！ 8 个帖子 - 8 位参与者 阅读完整话题
ruoyi框架实际上用起来还是有点臃肿了，有没有更轻量级适合敏捷开发原型的框架？（多端适配）。感谢回答 1 个帖子 - 1 位参与者 阅读完整话题
相信大家或多或少都接触过 Superpowers、GSD 和 Gstack 这三个框架。今天想分享一个将三者结合起来、更好辅助开发工作的方法——这也是我在阅读一些文章后获得的启发。最近使用下来，最直观的感受是： Gstack 的方向决策功能非常好用，个人认为远强于单纯的 brainstorming 。话不多说，接下来就讲讲如何将三者有机结合。 核心结论 在整合之前，先明确三者的定位： Gstack 负责决策 GSD 负责稳定上下文 Superpowers 负责执行 三大框架核心信息 1. Superpowers（执行层） 核心 ：聚焦代码落地执行 优势 ：闭环开发（需求澄清 → 规划 → TDD → 验收），流程严谨，执行稳定 适配场景 ：需求明确的开发任务 痛点 ：小任务下流程略显冗余，前置环节偏重 2. Gstack（决策层） 核心 ：模拟虚拟团队（CEO / 设计师 / 架构师 / QA 等）进行决策评审 优势 ：需求梳理、多视角评审，产品/架构/安全校验能力强 适配场景 ：需求模糊、边思考边开发的探索性工作 痛点 ：全量开启时较臃肿，单技能消耗 token 超过 10K，执行环节相对薄弱 3. GSD（上下文层） 定位 ：上下文工程工具，而非编码框架 核心 ：固化项目规范、状态与边界，解决长期项目中上下文失效/漂移的问题 优势 ：跨会话保持项目信息稳定 痛点 ：无独立代码交付能力，需要搭配执行/决策框架使用 整体结合流程 下面分享我近期实际使用的流程： 先用 Gstack 定方向、做决策 /plan-ceo-review ：检查产品方向的合理性 /plan-eng-review ：评审架构与技术方案 再用 GSD 固定上下文，防止漂移 /gsd-new-project ：将 Gstack 确定好的方案“钉住” /gsd-plan-phase 1 ：设计具体方法 然后用 Superpowers 真正写代码、做执行 /writing-plans ：编写计划（我仅使用了 /gsd-plan-phase ，两者二选一即可） /executing-plans ：执行计划 最后用 Gstack 收尾 /qa ：进行测试 One more thing 了解 Harness Engineering 的朋友都知道，无论是 Claude 还是 Codex，在启动时都会加载 skills 里的元信息。而上述三个框架的 skill 数量都非常多——尤其是 GSD。为了保持相对干净的上下文环境，我选择手动关闭（其实就是直接删除掉）其余不需要的 skill。 3 个帖子 - 3 位参与者 阅读完整话题
佬们，有推荐好用的开源前端对接后端的 agent 框架吗？类似于 minimax agent 的前端 ui ? 2 个帖子 - 1 位参与者 阅读完整话题
人格市场“玖帕喵”-已有180+篇（完善中） 开发调优 一个自建的prompt市场，目前主要是用来做角色扮演的，精选（置顶）有通用模板和通用破限模板（实测gemini-3-pro可用） 目前还在完善中，r18需要登录查看，防止网站太容易炸，可以用l站和github快速注册。个人维护所以可能有点小问题，欢迎大家来反馈哦 [Screenshot_2025-12-26-10-37-19-263_com.android.chrome] 就这个人格市场，稍微重构一下，给弄成开源框架，然后各部分元素可以用管理员账号在前端进行修改这样的，有没有搞头（ 1 个帖子 - 1 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 很抱歉一直给始皇和管理员们打扰，这次已严格按最新的要求重新设置好了 hi，社区的佬朋友，很长时间没有更新我们最新的情况和动态了，这次我们带来了全新的模型和框架。增加了更多的模型对接，此次更新我们带来了更多的惊喜给各位开发者，同时我们承诺最少3个月的大版本更新，1-2个月的小版本迭代更新，此次框架和之前有所不同。为帮助后面开源中融入更多的agent的理念重新打造 https://github.com/chatfire-AI/huobao-drama?tab=readme-ov-file#-项目简介 项目简介 Huobao Drama 是一个基于 AI 的短剧自动化生产平台，实现从剧本生成、角色设计、分镜制作到视频合成的全流程自动化。 火宝短剧商业版地址： 火宝短剧商业版 火宝小说生成： 火宝小说生成 核心价值 AI 驱动 ：使用大语言模型解析剧本，提取角色、场景和分镜信息 智能创作 ：AI 绘图生成角色形象和场景背景 视频生成 ：基于文生视频和图生视频模型自动生成分镜视频 工作流 ：完整的短剧制作工作流，从创意到成片一站式完成 技术架构 frontend/ — Nuxt 3 + Vue 3 + TypeScript (纯 CSS，无 UI 框架) backend/ — Hono + Drizzle ORM + Mastra AI Agents + better-sqlite3 configs/ — config.yaml 配置文件 data/ — SQLite 数据库 + 生成资源文件 skills/ — Agent 技能定义 (SKILL.md) 分镜制作 AI 自动拆解分镜脚本 场景描述和镜头设计 分镜图片生成（文生图） 宫格图生成、切分与分配 帧类型选择（首帧/尾帧/分镜板） 视频生成 图生视频自动生成 TTS 配音生成 FFmpeg 单镜头合成（视频 + 音频 + 字幕） 整集拼接导出 资源管理 素材库统一管理 本地存储支持 任务进度追踪 AI Agents 内置 5 个 Mastra Agent，支持数据库配置和 Skill 扩展： Agent 职责 script_rewriter 小说 → 格式化剧本改写 extractor 角色 + 场景智能提取与去重 storyboard_breaker 剧本 → 分镜序列拆解 voice_assigner 角色音色自动分配 grid_prompt_generator 角色/场景/宫格图提示词生成 多厂商适配 类型 支持厂商 图片 OpenAI、Gemini、MiniMax、火山引擎、阿里、Chatfire 视频 MiniMax、火山引擎/Seedance、Vidu、阿里 TTS MiniMax 快速开始 环境要求 软件 版本要求 说明 Node.js 20+ 前后端运行环境 npm 9+ 包管理工具 FFmpeg 4.0+ 视频处理（ 必需 ） 安装 FFmpeg macOS: brew install ffmpeg Ubuntu/Debian: sudo apt update && sudo apt install ffmpeg Windows: 从 FFmpeg 官网 下载并配置环境变量 验证安装： ffmpeg -version 配置文件 复制并编辑配置文件： cp configs/config.example.yaml configs/config.yaml 配置文件格式（ configs/config.yaml ）： app: name: "Huobao Drama API" version: "1.0.0" debug: true server: port: 5679 host: "0.0.0.0" cors_origins: - "http://localhost:3013" database: type: "sqlite" path: "./data/huobao_drama.db" storage: type: "local" local_path: "./data/storage" base_url: "http://localhost:5679/static" ai: default_text_provider: "openai" default_image_provider: "openai" default_video_provider: "doubao" 说明 ：AI 服务的具体 API Key 和模型参数在 Web 界面的「设置」页面中配置。 安装依赖 # 克隆项目 git clone https://github.com/chatfire-AI/huobao-drama.git cd huobao-drama # 安装后端依赖 cd backend && npm install # 安装前端依赖 cd ../frontend && npm install 启动项目 方式一：开发模式（推荐） 前后端分离，支持热重载： # 终端1：启动后端 cd backend npm run dev # 终端2：启动前端 cd frontend npm run dev 前端地址: http://localhost:3013 后端 API: http://localhost:5679/api/v1 前端自动代理 /api 和 /static 到后端 方式二：单服务模式 后端同时提供 API 和前端静态文件： # 1. 构建前端 cd frontend && npm run generate # 2. 启动后端 cd ../backend && npm start 访问: http://localhost:5679 数据库 数据库表在首次启动时自动创建，无需手动迁移。默认路径 data/huobao_drama.db ，可通过环境变量覆盖： DB_PATH=/path/to/your.db npm start 1 个帖子 - 1 位参与者 阅读完整话题
36氪获悉，江特电机公告，公司与深圳市裕同包装科技股份有限公司签署了《战略合作框架协议》。根据协议，双方将在碳纤维、包装等领域展开长期合作，推动相关领域的业务发展。
当地时间4月16日，谷歌推出专为构建定制化AI设计的合成数据生成框架“Simula”。谷歌指出，AI的大规模集成需要模型具备处理稀缺、隐私敏感或非常规应用场景的能力，而传统的互联网数据正面临成本高、获取难及合规风险等挑战。Simula通过“首要原则”和机制设计提供更严谨的合成数据，弥补了现有生成方法缺乏逻辑精度的缺陷。（界面）