- DS2026-08-17
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 开源标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
项目地址： GitHub - honestDS/MonoLight: MonoLight 是一个专注于安全执行与人机协同的通用自主智能体（General Autonomous Agent）运行时。 · GitHub
求反馈
MonoLight 现在还处于快速迭代阶段 非常希望各位佬能在空闲时间尝试一下 作为作者 我希望能获得尽可能多的真实使用场景下的问题/BUG 无论是在仓库提 ISSUE 进行反馈 还是在该帖子下回帖留言 我都会持续关注并认真阅读各位提出的问题 并在后期的迭代过程中尽力修复或满足需求
一些思考
MonoLight 从立项开始一直到现在 我有一直在想它到底要怎么落地、变现点在哪里
但一直没有想通 因为这个项目从最初开始搓的目的就不是为了变现 而纯粹是个人兴趣和一种尝试 我想尝试双模型审计这个概念是否真的能走的通 想把渠道调度和执行流调度整合成一个单一项目
所以它最终长成了现在这个样子
核心功能中 有一大堆都属于我认为的 一个agent类项目该有的基础功能 而不是亮点 但它们又不得不做 因为如果分开做成独立项目 那就又回到了分散部署+分散维护的问题上
关于AI落地 如果各位佬有除了coding以外的场景落地建议或想法 也欢迎在评论区交流~
核心功能
已知问题
未来规划
是又一个agent项目吗
好吧 MonoLight 确实是一个agent项目 但它的出现是为了解决一些我自己的特殊需求
- 在给予agent尽可能多的权限和自主决策权后 如何保证它不会把我服务器玩坏或者删掉我的项目？
- 我不想分别维护多个项目 比如newapi+napcatqq+astrbot 这很强大 但也很累 且定位排查问题需要贯穿多个项目
- 在agent不小心进入了交互式shell工具后(概率很大 提示词约束效果不如预期) 如何优雅结束？难道只能等timeout吗？
- 长期记忆系统只能依靠三方插件或其他外置项目、文档来达到吗？长期记忆的召回/新增/更新/淘汰机制是否有更工程化的手段？
- 当前的本地agent体系配置复杂 非专业用户或发烧友配置起来很麻烦 有没有门槛更低的方案？
以上这些问题在当时(2026年3月份) 我并没有找到现成的开源解决方案 所以只好又一次自己造轮子了 但至少我觉得 这个轮子能帮我深入的思考:agent是否有可能在未来成为一种成熟的人机交互方式
是缝合怪吗
是的
MonoLight 吸收了newapi的渠道调度思想、astrbot的消息平台架构思想、vibe coding工具的人工确认机制 同时结合我自身对agent安全的理解 把所有东西全缝进了MonoLight中
是AI造的屎山吗
是AI造的没错 但我个人认为至少截至现阶段 它还不是屎山 且听听我的开发方式：
- 在项目初期(2026年3月) gpt5.5时代 模型在长任务中的表现 问题很明显 即:目标遵循难、局部最优目标导致顾头不顾屁股 所以我在立项的初始阶段的第一件事就是写文档
我跟AI沟通 表达我的项目的架构预期、代码风格要求、开发规范要求、代码审查要求等各种约束预期 最终让AI生成了三份项目文档：README、架构文档、开发规范文档 具体文档内容也已经放在仓库公开 此处不再熬述
- 项目中期也就是上个月(2026年7月) gpt5.6发布 当我继续使用以上方式使用5.6模型时 我发现它的主动性极强 且能够完美遵守文档约束、和prompt约束 所以我开始尝试更激进的开发方式：我完善了上边提到的三份文档 目标就是让它根据文档的严格约束 自行根据我的新增需求对项目进行持续的迭代开发 而不是一步步引导AI先改哪一块后改哪一块
- 经过初步的探索 我发现它几乎能够完美的执行所有文档的约束条件 并且在主动复查过程中发现问题并进行二次修改 而不是那种“我改完了 你检查一下吧”的感觉 因此 我再次完善了文档 强制要求它每次新增/修改代码时 必须同步新增或修改对应的测试用例 且每次修改完代码必须运行全部测试用例并检查报错 若有报错必须自行检查是需要更新测试还是修复代码
- 以上方式极大的提高了项目的开发效率 且必须人工介入的频率相比5.5时代更少 但有时候 AI还是有可能在新增一个大需求时产生目标偏移 做着做着就偏离了我原本的设计 所以 在之后的迭代过程中 若设计较大的功能新增或重构 我会先跟它讨论方案、确定方案、生成规划文档(含验收标准)、复查规划文档、生成TODO拆分任务 然后再根据规划和TODO一步步进行改造
预览图
更新日志
2026-08-20 更新日志 新增一体化部署与初始化引导
PR/Issue
[!IMPORTANT]
项目当前处于早期活跃开发阶段 架构仍在快速演进中 PR暂缓 但非常欢迎通过 ISSUE 报告使用中遇到的问题或提出改进建议主楼 - 秦始皇-linuxdo2026-08-17
项目不错，就是UI太丑了一点吧，现在还用上古时期的后台ui风格
- DS2026-08-17
哈哈。。UI这块我是用gemini根据我的审美出的设计稿
可能我审美确实老了。。 ^-^
经典/现代主题已列入计划 感谢佬的反馈~
2026-08-20 01:24
未来规划修改了。。打算重构UI 思考了下单人维护双UI可能精力不太够 ^-^
- captain2026-08-17
自己做agent runtime吗？我看了你这个核心功能，我之前也在做这个，后续直接放弃了。
- DS2026-08-17
- 秦始皇-linuxdo2026-08-17
佬，更新一下UI吧，自己用无所谓，但是做开源肯定要好看
- captain2026-08-17
理由就是无意义，深入思考过的，把模型前进方向，把厂商迭代最快、最容易被收编的一层当作了核心功能。
而且你这个webui形式你认为会不会有人用，我之前第一版做的TUI，然后再桌面版，后续深入思考后直接改方向了
- DS2026-08-17
不不 我的核心是二次审计 其他的都属于基础功能^-^
我觉得这一块单靠模型自身的约束很难 并且非常容易被提示词误导
我现在的实现方式是将审计流程独立出来 虽然也是使用模型 但它的上下文是干净的 并且在审计处理之后的结果中 只将触发分数和结果(自动拒绝/用户拒绝)告知主llm 不告诉它不通过的原因 这样可以避免主llm想办法自行绕过审计机制或让审计误判
关于webui 其实只是未了在项目初始部署时能方便的进行配置 后期主要是针对IM侧的 webui只是个控制台 并且也计划将系统配置做成工具 让用户可以用自然语言去修改配置信息 但边界处理肯定要一点点打磨
可能我确实不太会营销 没能在帖子里把主要差异展示出来 ^-^
补充了一些项目背景信息 佬有空的话可以看看 ^-^
- DS2026-08-20
2026-08-20 更新日志
- 新增setup部署引导 系统在初次运行时会引导用户进行基础配置 帮助用户快速跑通核心流程
- 新增一体化部署、前后端分离部署、开发模式 三种启动方式 其中一体化部署可使用一行命令自动启动前后端,无需分离启动
