先说方法。功能对比表是最没信息量的东西：两边都能打勾，勾还都一样多。真正决定你用着顺不顺手的是它把什么东西放在了哪里——队列的真相存在哪、记忆存在谁家、执行层归谁改、语法为谁设计。这四件事一旦不同，后面所有差异都是它的后果。
hive：队列的真相放在 Git 里
对比对象：Redis/RabbitMQ 任务队列、Celery、以及 LangGraph / Dify / Coze 这类编排框架。
它们通常的假设
任务状态需要一个专门的存储和常驻服务来管。你负责运维它、给它做高可用、给它写监控。
或者：编排逻辑写在代码里，一个进程内的图决定下一步走哪。
我们的假设
如果一批活是「几十张卡、每张几分钟到几小时、人要看结果」，那么运维一套队列的代价比队列本身还大。
于是队列就是仓库里的 tasks/ claims/ results/ 三个目录。领取靠 git push 的原子性，谁先推上去谁拿到。机器挂了，租约超时自动回收重派。
所以
选 hive：你想让几台闲置机器、几个不同的 AI 客户端并行干同一批活，并且希望每一步都留下可审计的记录；你能接受「一台机器上要能跑 git」。
选队列服务：每秒上千次任务、需要精确的延迟重试、需要水平扩展到几十个 worker。hive 在这个量级上不合适，它的吞吐上限就是 Git 的推送速度。
选编排框架：你要的是在应用内定义一条固定流程（检索→生成→校验），而不是把活派给机器和别的 Agent。
lightmem：记忆存在你自己机器上
对比对象：托管型记忆服务（Mem0、Zep 等的云版本）、以及「把聊天记录塞进向量库」这种做法。
它们通常的假设
记忆是一个云端 API。你调用它，它替你存、替你检索、替你算账单。上手最快。
或者：记忆就是历史对话的向量检索。存下来、按相似度捞回来。
我们的假设
记忆里有你的架构决策、客户信息、还没公开的方案。把这些整段交给第三方，是个需要慎重的问题。
而且「相关」不等于「该记」：一条三个月前的临时结论和上周定的接口约定，向量距离可能一样近。所以 lightmem 按温度分层（分钟 / 天到月 / 长期 / 归档），检索时再融合时效、来源、实体几路信号。
所以
选 lightmem：你机器上跑着好几个 AI，希望它们共用一份记忆；团队小、数据敏感；不想为记忆单独付月费。solo 档就是一个 SQLite 文件，不装数据库、不装 Docker。
选托管服务：你要的是最快接上、完全不想管运维，并且数据不敏感。它们在这件事上确实更省事。
别用向量库硬凑：如果你已经在为「捞回来的记忆经常不对」发愁，问题通常不在向量模型，而在没有分层和时效。
lightharness：执行层是给你改的
对比对象：LangChain / LlamaIndex 这类成熟框架，以及各类低代码 Agent 平台。
它们通常的假设
框架提供尽量多的抽象和集成，你按它的方式拼装。遇到框架本身不合意的地方，绕过它比改它容易。
我们的假设
Agent 的行为最终由执行层决定：上下文怎么裁剪、工具怎么调、失败怎么重试。这一层如果是英文的、抽象的、几千行的，你就只能调参数，不能改逻辑。
所以 lightharness 用光明 1:1 复刻这套机制，代码是中文的，插件可以热加载。目标是你能读懂每一行并改掉它。
所以
选 lightharness：你想搞清楚 Agent 内部到底怎么跑的；你需要改上下文策略、改重试逻辑、改工具选择；你不介意它还在研、功能面比成熟框架窄。
选成熟框架：你要做产品、要最快接上几十种模型和工具、要有人替你维护生态。这时候「可改」不是优点，是负担。
光明：为中文母语者设计，不是为取代 Python
对比对象：Python、以及各种「中文编程」尝试。
常见的中文编程
把关键字换成中文，其余照搬。结果是两种语言拼在一起，读起来更别扭，也解决不了「初学者先被语法劝退」的问题。
我们的做法
以 30 个永久冻结的核心字为内核，往上分七层文体：L1 白话体给初学者，L2 文言体支撑强类型工程，L3/L4 直接嵌 SQL、Python、C、Go。
同一门语言，学习时写白话，交付时写文言——不用换语言，只换文体。编译器自己用自己写成。
所以
值得试：你在教别人编程；你要给非程序员一套能读懂的业务规则表达；你想让代码和中文文档长得一样。
不必换：你 Python 已经很熟，团队也都用 Python。换语言几乎没有收益，我们不建议为了「支持国产」去换工具。
你的情况，对哪一行
| 你的处境 | 建议 | 下一步 |
|---|---|---|
| 几个 AI 各干各的，背景每次重讲 | lightmem，半小时能跑通 | 上手 → |
| 三台闲置机器，想让它们一起干活 | hive，需要能 push 的远程仓 | 上手 → |
| 要用 Agent 做正式产品，接几十种工具 | 用成熟框架，别用我们的在研项目 | 先看边界 → |
| 想读懂 Agent 执行层并改掉 | lightharness | 上手 → |
| 教别人编程，或让非程序员读得懂代码 | 光明 L1 白话体 | 上手 → |
| 每秒上千次任务，要严格的延迟重试 | 用成熟队列，hive 不在这个量级 | 看 hive 的代价 → |
| 要一个人把一条业务线跑起来，缺的是方法 | 看按职业写的方案 | 方案 → |
说明：上面对其他方案的描述是一般性观察，各家产品差异很大，具体能力以官方文档为准。我们自己也还在迭代，档案页里的「边界」一节比这张表更该看。