开源harness一夜冒出十几个，AI代理的信任问题终于有人管了

这周Hacker News上冒出来一堆agent harness项目，我数了数，光是热门榜上就有十几个。有个叫Lemmaflow的项目直接开源了，定位是"AI原生应用的信任马具"。仓库里star涨得不算快，但看issue区讨论的深度，明显是干过真活的团队做的。另外我翻了翻别人整理的生态地图，截止到现在，类似的开源harness项目已经有几十个了，goose这类背靠大厂的有三万多star，gemini cli这种干脆就是官方出的。

这个赛道突然热闹起来，我倒不意外。

我一个月前开始给客户做AI代理落地的项目，当时就卡在信任问题上。代理该有的能力都有，能调工具、能查数据库、能写邮件，但你真让它自己跑完一个跨部门的工单流程，没人敢拍板。为什么？因为它干的事没法审计，权限边界也很模糊。就像公司里来了个能力很强的实习生，什么都能干，但你不敢把钥匙都给他。

agent harness本质上就是在做这件事：给AI代理一个操作系统，管理它的权限、记忆、工具调用，以及每一步决策的审计日志。

把信任机制开源，是这条路线上很关键的一步。

先说说我看到的行业数据。从2026年初开始，agent harness方向的融资和收购明显变多了。各大云厂商也在推自己的闭源方案，比如aws那个深度绑定云服务的coding agent。开源这边更热闹，有做eBPF观测的agent sight，有做MCP协议的适配层，还有像我之前提过的记忆层方案。今天lemmaflow又加上了权限和审计这一环。

这么多项目挤在同一个赛道，说明什么问题？说明大家都看到了同一个痛点：AI代理的能力已经够用，真正的瓶颈在治理。就跟当年的kubernetes一样，容器技术本身不是难点，难的是怎么在几千个容器里做调度、权限和可观测性。

从架构上看，这些harness的思路其实殊途同归。都是在外层包一层代理，统一接管工具调用的入口，然后在这个入口上做权限控制、日志记录、人工审批的插入点。lemmaflow比较有意思的地方，是把四眼原则内置了，就是那种关键操作必须两个人确认的制度，做成了代码层面的强制流程。这个设计我在客户那边提过，但当时没有现成工具支持，只能靠流程硬管。

不过说实话，这个领域现在的状态有点像2015年的容器圈，项目非常多，但标准还没形成。

我这两天试下来，最大的感受是：每个harness都有自己的配置语言和权限模型，换一个工具就要重新学一套。这对早期采用者来说是正常的，但企业要做技术选型的时候就很头疼。

对标海外案例的话，这波agent harness的发展轨迹，很像当年CI/CD工具的演进。一开始是jenkins这种全家桶，什么插件都能装，什么流程都能配，但用起来很重。后来gitlab ci和github actions把常见场景封装好，才真正普及到普通团队。agents harness现在还在jenkins阶段，谁能做出github actions那种体验，大概率就是最后的赢家。

具体到lemmaflow这个项目，我看了一下它的设计，权限模型做得比较细。不像有些工具就分个管理员和普通用户，它支持给每个工具调用单独设置审批策略。比如读操作自动放行，写操作需要一个人审批，删除操作要两个人确认。这种粒度在企业场景里是对的，毕竟不是所有操作的风险等级都一样。

不过我也要泼点冷水。现在的开源harness，绝大多数还是给开发者自己用的。企业要落地，还得在周边补很多东西：身份认证怎么接现有的SSO，审计日志怎么对接SIEM，配置怎么做到热更新。这些脏活累活，开源社区一般没人愿意干。

我客户那边最近在做技术预研，我给他们提了个建议：别急着选型，这半年是爆发期，很可能三个月后就有大厂出手整合。先拿两三个开源项目做概念验证，跑通一个具体的业务场景，把评估维度定清楚，比如权限模型的细粒度、审计日志的完整性、运维的复杂度。

另外可以关注一下商业化的迹象。这个赛道的商业模式大概率是提供托管版本和合规能力，类似supabase的发展路径。

最后说个实操层面的建议。如果你所在的公司已经开始用AI代理处理业务，或者正在规划，建议你现在就开始积累agent的访问审计数据。这个数据越早积累越好，因为信任体系的建设，本质上是一个逐步建立信誉记录的过程。等机制成熟了，这批数据就是你的入场券。

---

本文编译自 Hacker News，原文：Show HN: Opensourcing Lemmaflow – A trust harness for AI-native apps | Hacker News
版权归原作者所有，本文为基于公开报道的编译与独立分析。