2. Linux.do
  3. [开源自荐] MonoLight 为 Agent 增加独立审计层的安全执行运行时

[开源自荐] MonoLight 为 Agent 增加独立审计层的安全执行运行时

DS 2026-08-17 10:21 1

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：



  • 我的帖子已经打上 开源推广 开源标签： 是

  • 我的开源项目完整开源，无未开源部分： 是

  • 我的开源项目已链接认可 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 报告使用中遇到的问题或提出改进建议


最新回复 (8)
  • 秦始皇 08-17 11:03
    1楼

    项目不错，就是UI太丑了一点吧，现在还用上古时期的后台ui风格

  • DS 楼主 08-17 13:54
    2楼

    哈哈。。UI这块我是用gemini根据我的审美出的设计稿

    可能我审美确实老了。。 ^-^


    经典/现代主题已列入计划 感谢佬的反馈~



    2026-08-20 01:24


    未来规划修改了。。打算重构UI 思考了下单人维护双UI可能精力不太够 ^-^

  • captain 08-17 15:27
    3楼

    自己做agent runtime吗？我看了你这个核心功能，我之前也在做这个，后续直接放弃了。

  • DS 楼主 08-17 15:28
    4楼

    是的佬

    为什么放弃呢？

    我自己之前是用newapi+astrbot+napcatQQ部署 但是维护起来很累 所以就想做个缝合怪出来 一站式维护 ^-^

  • 秦始皇 08-17 15:29
    5楼

    佬，更新一下UI吧，自己用无所谓，但是做开源肯定要好看

  • captain 08-17 15:31
    6楼

    理由就是无意义，深入思考过的，把模型前进方向，把厂商迭代最快、最容易被收编的一层当作了核心功能。

    而且你这个webui形式你认为会不会有人用，我之前第一版做的TUI，然后再桌面版，后续深入思考后直接改方向了

  • DS 楼主 08-17 15:45
    7楼

    不不 我的核心是二次审计 其他的都属于基础功能^-^

    我觉得这一块单靠模型自身的约束很难 并且非常容易被提示词误导

    我现在的实现方式是将审计流程独立出来 虽然也是使用模型 但它的上下文是干净的 并且在审计处理之后的结果中 只将触发分数和结果(自动拒绝/用户拒绝)告知主llm 不告诉它不通过的原因 这样可以避免主llm想办法自行绕过审计机制或让审计误判


    关于webui 其实只是未了在项目初始部署时能方便的进行配置 后期主要是针对IM侧的 webui只是个控制台 并且也计划将系统配置做成工具 让用户可以用自然语言去修改配置信息 但边界处理肯定要一点点打磨



    可能我确实不太会营销 没能在帖子里把主要差异展示出来 ^-^



    补充了一些项目背景信息 佬有空的话可以看看 ^-^

  • DS 楼主 08-20 01:14
    8楼

    2026-08-20 更新日志



    1. 新增setup部署引导 系统在初次运行时会引导用户进行基础配置 帮助用户快速跑通核心流程




    1. 新增一体化部署、前后端分离部署、开发模式 三种启动方式 其中一体化部署可使用一行命令自动启动前后端,无需分离启动


* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐