最近 DeepSeek 开源了个叫 Harness 的新东西，讨论度挺高。我本来只是想去看看它的设计架构，学学人家怎么搭的。
结果看着看着，越看越不对劲。这哪是什么技术框架，这分明是一套企业治理的说明书。
大家都在说，DSH一切皆插件。模型是插件，工具是插件，权限是插件，连界面都是插件，全都能拆能换。
管这些插件的底层框架叫 Cordis，它只干一件事，管插件怎么装、怎么拆、谁依赖谁。
就是在这套插件管理里，我撞见了三个琢磨了好多年的东西。
第一个，是关于声明。
把隐性依赖摆出来
Cordis 里有个规矩，每个插件启动之前，得先说清楚自己需要什么。这叫 inject，注入。比如一个插件说，我需要模型服务，还需要文件系统。这两样都就位了，我才启动。中途文件系统要是没了，我就自动停，等它回来再接着干。
我当时看到这，愣了一下。
这不就是我们团队搞的那个 Manual of Me 么。
每个人写一份怎么跟我协作的手册。我几点精神最好，我讨厌别人怎么催我，我需要什么信息才能动手。把这些说不清道不明的东西，白纸黑字摆出来。协作的人就不用猜了，不用反复踩同一个坑。
公司级也一样。很多组织的 ways of working 为什么形同虚设，因为依赖关系全藏在老板和几个老员工的脑子里。谁离不开谁，谁卡着谁，没人说得清。真把它像 inject 那样一条条声明出来，很多扯皮自然就消失了。
（我现在就是在搞这个 ways of working）
第二个，是关于工具。
实践随问题来随问题走
dsh 里的插件，装装卸卸特别随意。今天加个搜索工具，明天换个模型，后天把权限改了，都不影响大局。
这让我想起这些年带团队最头疼的一件事，流程僵化。
站会、回顾、用户故事地图、影响地图、康威审计，这些敏捷实践，本来是一个一个的插件。团队沟通出问题了，装个站会上去。需求理不清了，上用户故事地图。问题解决了，这玩意儿可以撤。
可现实里呢，很多公司把它们写进流程文档，变成雷打不动的规矩。不管有没有问题，站会都得开，回顾都得做。
实践应该是随问题来的，随问题走的。不是焊死在流程里的铁疙瘩。
第三个，是关于Preset分类。这个最让我高兴。啊哈！MICA 模型！！
MICA 分类与复杂度路由
dsh 里有四个预设模式，叫 preset。标准、程序化、极简、创造。给同一个模型配上不同的工具集和权限，等于给它分配了四种不同的工种。
这跟我自己捣鼓的一个模型几乎撞了个满怀。我管它叫 MICA。
M 是 Maintenance，日常维护。I 是 Innovation，创新。C 是 Construction，长期建设。A 是 Action，尽快响应。
四种类型，既是任务的类型，也是成员的角色属性。我一直觉得，治理一件事之前，先得搞清楚它属于 MICA 里的哪一类，再谈怎么管、谁来管。dsh 的 preset，几乎就是同一个东西，只是它管的是模型，我管的是人。
但真正让我拍大腿的，还不是这个对应。是它俩不一样的地方。
dsh 的模式，是人手动选的。你想用哪个，就切到哪个。
可现实里的任务会自己长大。
所以我自己加了一条规则。A 是默认起点。事情来了，先快速响应，别想太多，最小投入先动起来。一旦发现这事过于复杂，A 那点工具搞不定了，再升级。知道怎么做的，切到 C，长期建设。不知道怎么做的，切到 I，创新试错。
知道怎么做和不知道怎么做，这两条路完全不一样。前者靠经验和纪律，后者靠试错和运气。
哦对，还有个更妙的。
任务分类，路由给团队
这个 MICA，既能给任务分类，也能给团队分类。有的团队天生适合快速响应，有的团队就适合闷头搞长期建设。任务进来了，按复杂度归个类，再路由给擅长的那个团队。
你看，任务解构和组织解构，就这么在一个小小的分类上，接上了。
说到这，我得承认一件事。我研究 Harness，本来是奔着 AI 去的。结果它给我上的一课，跟 AI 没多大关系。
它教会我的，是组织这个事，也可以像代码一样，声明清楚依赖，随用随装工具，按复杂度升级打法。
至于这是不是 AI 时代组织该有的样子，我还没想透。但有一点我挺确定，那些改不动的组织，多半是既没声明依赖，又把工具焊死了，还拿一套打法应对所有事。
