凌晨两点，一个研发团队的CI看板亮起红灯。
修bug的智能体A提交了一份补丁，说"已修复"。审查智能体B紧接着报告："这个补丁会引发新的回归。"监工的人类工程师揉揉眼睛，看着两个都被标为"高能力"的智能体互相打脸——他没法在五分钟内判断谁对谁错，于是干了所有疲惫工程师都会干的事：把两份输出都驳回，自己上。
这就是今天大多数多智能体系统的真实困境：智能体越多，人越累。不是因为它们不聪明，而是因为没人知道这一刻该信哪个。
Harness解决了"怎么跑"，但没解决"信谁"
过去一年，"Agent Harness"成了人工智能领域的热词——Claude Code、Cursor、OpenClaw、Hermes这些工具的本质，都是给LLM套上一层"外壳"：负责工具调用、循环控制、上下文管理、失败重试。Harness把一个会聊天的模型，变成了一个能动手干活的智能体。
但Harness解决的是单个智能体怎么把活干完。当场景升级到多个智能体协作+人类在环+开放接入——比如一整条软件研发流水线上，需求拆解、代码生成、测试、审查、部署各由不同来源的智能体负责——一个新问题浮出水面：
谁的输出可以直接采纳？谁的建议要复核？谁的权限该被悄悄降级？
Harness不回答这个问题。它只让每个智能体跑起来，不告诉你哪个值得信任。
OpenTrust就是补上这一层的东西——你可以把它理解为工程智能场景下的Harness增强版：在"怎么跑"之上，加一层"信谁、给多少权、什么时候该警觉"的信任中枢。
有OpenTrust和没有OpenTrust，差在哪？
没有它：每个智能体都是"应届生"，无论它已经成功交付过1000次还是刚刚搞砸过3次，下一个任务来了，调度器对它的态度是一样的。出问题靠人事后救火，信任靠开发者拍脑袋。
有它：每个智能体（也包括每个真人成员）都有一条持续演化的信任曲线——
干得稳，信任缓慢爬升，关键任务自动优先派给它；
出一次重大失误，信任快速回落，下一次它的输出就会被自动标记"需复核"；
长期不活跃的"老资历"也会被时间稀释，防止吃老本；
每一次信任变化，都能追溯到具体的协作事件，不是黑箱评分。
结果：同样一个多智能体打架的凌晨，监工的人看到的不是"两份矛盾的报告"，而是"A的信任曲线本周三连降，B在同类回归判断上历史准确率94%"——五秒内做决定，而不是五十分钟。
为什么是工程智能
工程智能（设计研发、数据分析、运维、安全审计这一类）是当下Agent Harness落地最多、也最早撞上"多智能体协作"天花板的领域。原因很简单：
这正是OpenTrust选择的主战场：给工程智能领域的多智能体系统，装上一套能随协作一起成长的信任体系。让临时拼起来的人机混合团队，也能拥有老团队才有的那种默契——知道谁在什么时候，能扛什么活。
一句话
Harness让智能体跑起来。
OpenTrust让一群智能体跑得高效又省心。
English
