人机环中的三种“算”：计算、算计与天算决定系统成败

1. 从一次调度系统复盘说起三种“算”决定了项目成败做系统设计这些年我发现自己对“算”这个字越来越敬畏。2024年初我参与过一个自动化仓储项目的复盘项目本身不算复杂就是AGV搬运、上下架、订单批次合并那一套。算法团队当时用整数规划做了全局调度实时率、路径代价、设备利用率在仿真环境里都非常漂亮。但上了现场以后出现了两个谁都没预料到的现象一是部分搬运工开始绕过系统赋予的“人工接管”权限把任务改到自己熟悉的巷道二是午高峰时段只要调度策略一激进整个场地就会出现五六分钟的拥堵哪怕同一套参数在上午跑得特别顺。我们花了很长时间优化计算层调整惩罚系数、换路径规划算法、增加预测模块结果收效甚微。直到团队里一位老工程师说了句话我们一直在算“怎么把活排得更优”但没算“人会怎么应对这套规则”更没算“场地本身长时间段的物理约束”。这段话直接改变了我理解系统的方式。后来我把它整理成一个朴素但很实用的框架就是“人机环中的计算、算计与天算”。很多人看到这个标题会以为这是哲学讨论但实际上它是一套非常落地的系统设计思路。这篇文章不绕弯子我直接把三层“算”的含义、边界、失效模式以及怎么把它们组合进同一个项目里讲清楚。无论你是做算法的、做产品设计的、做运营管理的还是单纯对复杂系统感兴趣这套框架都能帮你在拿到新问题时多一层判断力。1.1 “人机环”到底是什么一个不能简化成“人和机器”的分析单元“人机环”这个提法在工程、交互设计、智能系统等领域已经存在很久了。它指的并不是人、机器、环境三个孤立的要素而是三者相互耦合、相互制约、彼此输出的组合系统。人以作业目标为中心机器提供执行能力环境提供资源、边界和条件而三者之间没有任何一个可以单独决定系统最终走向。举一个最简单的例子一台物流分拣设备机器本体效率极高但放在一个空间拥挤、照明不足、操作台高度不适的物理环境里人的操作速度必然下降机器再快也喂不上料。反过来环境很宽敞但如果人机界面设计得一塌糊涂操作员频繁误触同样会拖垮整条产线。再进一步如果操作员的考核指标是“分拣数量”他就会下意识跳过质量抽检环节哪怕机器和算法都要求他严格执行流程。这说明一个什么问题说明单独谈“优化某个设备”或“提升某个算法精度”是没有意义的。人机环是一个整体任何一层的变化都会像涟漪一样传导到另外两层。最反直觉的地方在于越是引入智能化能力这种耦合效应越强。因为机器一旦具备自主决策人的角色就从“直接操作者”变成了“监督者、干预者、博弈者”人机关系一变人的行为就会跟着变系统对环境的影响方式也会变。这个连锁反应往往比任何一个算法模块的缺陷都更决定项目死活。所以我现在看任何一个系统第一反应不是看它的技术方案有多先进而是先画一张人机环关系图谁是人谁是机什么是环它们之间交换什么信息、什么能量、什么约束。这张图画清楚了后面所有技术决策才有讨论前提。1.2 三种“算”同时在场计算、算计、天算的定义与关系中文里“算”字有多层含义正好对应了系统设计里三个不同层级的作用机制。第一层是“计算”。这是最狭义也最正式的含义用算法、模型、数据在明确约束下求精确解。它对应的是机器可以形式化的部分包括感知、建模、寻优、控制、预测。第二层是“算计”。这个词在日常语境里略带贬义但我这里取的是它的中性含义有意图、有博弈性地权衡利弊、预判他人行为。任何一个有目标的主体无论是人、组织还是另一套系统都会在规则之下做策略性应对。这种应对可能是正向的也可能是逆向的但它一定存在。第三层是“天算”。中国人常讲“人算不如天算”这不是迷信而是在表达一种系统观单个主体的策略计算会被更大尺度、更长时间维度的规律所约束和修正。这些规律包括物理规律、生态规律、市场规律、社会注意力规律等等。你算得再精妙只要和这些大尺度规律作对最终一定会被规律“找补”回来。三层算的关系可以这样理解计算负责“把能形式化的部分算准”算计负责“把人的策略性应对纳入设计”天算负责“认清哪些东西不可设计、只能顺应”。三者不是层级替代关系而是同时存在、互相制约。很多时候项目失败不是某一个“算法错了”而是三层算力之间出现了断层计算层以为自己说了算算计层的真实行为却不买账或者算计层设计得再精巧天算层的大系统规律直接不给你发挥余地。2. “计算”的本分形式化在什么情况下有效又在什么情况下失效先把计算层说透。因为大多数系统设计者最熟悉、也最依赖的就是计算层它提供的是一台机器的“确定性”。但这种确定性是有前提的前提一旦发生变化计算结果就从“最优解”直接变成“最优的错解”。2.1 计算很强强在有边界、可重复计算层能解决的核心问题可以归纳成五类。状态感知用传感器和数据把系统当前状态表达出来预测推演基于历史数据和模型估算未来状态方案寻优在约束条件内寻找最优或可行解控制执行把决策结果转换成机器可执行的动作复盘迭代用回测、统计推断、效果评估来改进模型。这五类能力的共同点是什么是可形式化、可验证、可重复。同样的输入输出是稳定的输出稳定就能做回测能回测就能逐步优化。这一点极其重要因为算计和天算这两个层面都很难做到这种程度的可验证性。所以不管系统复杂到什么程度计算层永远是最有价值的基石。没有它后面两层讨论都是空中楼阁。但问题也恰恰出在这里计算层太“好用了”好用到现在很多人把它当成了系统设计的唯一维度。算法工程师写代码优化的是目标函数产品经理定指标盯的是数据看板管理者看报告关心的是KPI走势。所有动作都在计算层闭环仿佛只要模型够好现实就会自动跟着变好。这种思维在物理规律稳定、人为干扰极小的环境下是成立的但一旦环境开始波动、人开始“不按套路出牌”计算层的确定性就开始失真。2.2 计算的三个失效面目标失真、前提失稳、语境失全我总结过计算层的三类典型失效情况几乎覆盖了大多数“算法看起来很准实际用起来不灵”的场景。第一个失效面叫目标失真。我们在系统里优化的大量指标其实并不是真正的业务目标而是“方便被量化的代理指标”。仓储调度里算法优化全局最短路径但业务真正关心的是履约稳定性和顾客体验路径最短不等于订单及时率高更不等于现场作业疲劳度低。再比如推荐系统算法优化点击率但平台真正需要的是长期用户信任这两者在短期内可能方向一致长期却可能严重背离。目标一旦失真计算层越强大系统反而越可能朝错误方向高速狂奔。第二个失效面叫前提失稳。形式化模型必须以假设为前提假设设备稳定、假设需求平稳、假设所有节点畅通。但现实系统无时无刻不在“蠕动”某台AGV因为低电量临时脱离队列某条巷道因为货物堆放被堵住某批订单突然加塞变更优先级。前提只要一破模型输出就会从“最优方案”瞬间变成“错误方案”。很多做智能调度的人都有这种体验模型在仿真里跑一百遍都没问题一接实际数据就频繁告警原因往往不是模型写错了而是模型的假设前提太干净了干净到现实世界根本不具备。第三个失效面叫语境失全。计算只能处理那些已经被表达出来、被数据化的变量。但真实系统里大量决策依赖的语境信息比如操作员的情绪状态、管理层的考核导向、团队内部长期形成的协作习惯根本无法进入目标函数。这些语境变量虽然没有被算进去却有资格否决目标函数的执行效果。它们像水面下的冰山算法看见的只是露出水面的那一角。一句话总结计算像GPS导航它规划的是“忽略司机情绪、忽略封路信息”的直线最优发布最优路径依赖实时路况、限行规则和用户偏好。但导航再好只要司机不是想去最近的目的地而是因为那条路让他心烦而主动改道算法结果就必然失真。2.3 一个典型的“算不准”复盘问题往往出在形式化的前提而不是算法本身回到那个AGV项目。第一次优化失败后我们把目标函数改成了动态惩罚机制希望惩罚那些会引发拥堵的路径策略。但连续观察几天拥堵依旧准时出现。后来翻了两个月的现场日志才发现真正的原因根本不在目标函数里调度策略激进的时段恰好是工人午饭前后的时间段。午饭前大家都想把手头任务收尾形成了一股同时向高密度巷道聚集的冲动午休结束后又集中返回作业区短时间内制造出剧烈的人流和设备流叠加。这就是一个很典型的“前提失稳”加“语境失全”的混合案例。算法假设现场流量在时间维度上是均匀或平滑变化的但人的作息节律制造了明显的尖峰影响流量的关键因素不是AGV路径规划而是人的生理节律和工作心理。算法再聪明也算不出“工人想吃午饭”这个变量。后来我们只是把午间调度策略改成保守模式拥堵率立刻明显下降。这段经历让我形成了一条经验当计算层反复调优无效时大概率不是参数没调好而是模型边界和真实世界的边界没有对齐。这时候最该做的不是继续加参数而是回头审视我把什么问题形式化了有什么该被形式化的问题被我漏掉了漏掉的变量是不是才是真正的主变量3. “算计”的复权别把人的策略性应对当成噪声如果说计算层是“机器的逻辑”那么算计层就是“人的逻辑”。系统设计里最常犯的一个错误是把人的策略性应对当成随机的、可以忽略的干扰噪声。实际上这不是噪声这是有意图的博弈行为它比噪声更难对付也更容易被设计者误判。3.1 人不是“理性平均值”人是博弈者算计的正与反几乎所有规则被公布的那一刻起就会出现两类人一类顺着规则做事一类绕开规则做事。系统设计者往往习惯把第二类行为标记为违规、恶意、bug但从行为者的视角看这不过是在资源限制下的适应性策略。任何有自主目标的主体都会对外部约束做权衡——遵守规则带来的收益高就遵守绕开规则收益更高且风险可控就绕开。这种现象在经济学和管理学里早已被反复验证过叫做“激励扭曲”或“套利行为”。但我更愿意把它看作一种决策智能它帮助主体在约束条件下最大化自身利益只不过主体的利益排序未必和系统设计者的排序一致。一线操作者绕过调度系统走熟路从“减少个人体力消耗、保持熟悉感”这个目标看完全理性但从“系统全局稳定”的目标看就成了需要治理的偏离行为。两种理性碰撞的结果就是系统实际运行状态和仿真状态的分道扬镳。所以我现在特别反感“唯一正确答案”这类表述。在一个有人参与的系统里几乎不存在唯一正确答案只存在“在某个博弈格局下各方利益暂时达成均衡的可行解”。所谓“算计”就是要在这种均衡形成之前提前预判每个主体的应对方式。3.2 好的系统设计不消除算计而是引导算计理解了算计的必然性之后真正的问题就变成了既然人一定会算那设计者应该怎么和这种算相处我的答案是不要试图消灭它而是引导它。消灭算计意味着把人的所有自由度都锁死结果是系统失去灵活性同时逼出更多隐蔽策略。引导算计意味着设计者明确知道“人在什么端口上会算”然后主动把那些端口的设计目标调整为系统性预期的方向。实操上有三种被验证过比较有效的方式。第一是激励结构对齐。把个人利益和系统利益写进同一个公式。比如调度系统允许操作员选择任务但不同任务积分不同积分又与个人绩效挂钩。这时候“为自己选任务”和“为系统完成任务”就是同一件事算计自然变成系统动力的放大器。第二是规则留出选择空间。不要用算法把所有决定都做完而是在少数关键节点允许用户行使有限的修改或覆盖权。这看起来是“放权”实际上是在降低被对抗的可能性。人有干预感就更愿意配合有自主感就更少产生对抗冲动。第三是建立博弈反馈通道。把“被绕过的规则”当成信号而不是违规。每一条被绕过的规则都暴露了原规则与现实之间的裂痕系统设计者应该快速修正这些裂痕而不是记仇式地加惩罚。历史上很多成功的协议都是在“被钻空子—修复—再被钻空子—再修复”的过程中成熟起来的。这三种做法看似是让步本质上是把治理成本转变成设计成本把“事后对抗”转变成“事前设计”。3.3 把“算计”纳入建模的简易方法三类主体清单很多技术团队一听“要把算计纳入建模”第一反应是“这怎么建模量化不了”。我提供一个非常简单的方法不需要复杂算法只需要一张表。任何一个包含人的系统至少先拆出三类主体。第一类是执行者也就是手脚直接接触系统的人关心他们从行为中获得了什么收益会怎样调整行为频次第二类是使用者也就是把系统当工具的人关心他们会把哪些功能变成习惯把哪些功能变成规避对象第三类是管理者也就是制定规则和考核的人关心他们会根据指标怎么调整策略甚至怎么改变工作流程。针对每一类主体列一行这样的清单主体身份、拥有的自由度、能看到的信息、其利益函数、最可能采取的策略、该策略会利用哪条系统规则、如何通过激励方式反转策略结果。这张表写完之后系统设计者通常会有两个发现第一自己原来一直是被“算计”的对象只是没意识到第二大部分所谓恶意行为其实都是可以预判和引导的正常博弈策略。举个生活化的类比就像一个城市设计者不应该假设所有行人都会走斑马线而是默认有人会斜穿马路、有人会翻护栏然后把护栏高度、路口间距、斑马线位置当成博弈变量来调整。这才是把算计纳入设计的姿势。4. “天算”的提醒系统自组织和环境约束决定最终空间如果说计算层是“机器的逻辑”算计层是“人的逻辑”那么天算层就是“更大系统自身的逻辑”。这一层最容易被忽略也最让设计者无力因为它不服从任何单个主体的意志。4.1 把“天算”翻译成现代系统语言大尺度规律的总称“天算”这个词带着很强的文化意味但我建议把它理解成一组大尺度规律的集合物理规律比如能量守恒、熵增、摩擦损耗生态规律比如承载能力有限、反馈回路断裂便走向崩溃市场规律比如供需弹性、均值回归社会规律比如注意力稀缺、信任成本递增。这些规律的共同点是它们不因为某个个人或组织的意愿而改变只在更长的时间尺度和更大的空间尺度上稳定发挥作用。我们常说的“人算不如天算”翻译成系统语言就是说任何个体的策略计算在大尺度规律面前都只是局部调整无法改变系统收敛方向。这里有个关键认知天算不是“不可知”的玄学它恰恰是可分析的只是分析尺度要大得多。一个人可以在短时间内用算法优化一条产线的效率但他无法用一个季度的时间改变一座城市的交通吞吐总量上限。城市总吞吐量就是一种天算它由道路空间、信号配时、驾驶员反应速度共同决定单台车的导航再聪明也只是在“整体容量”这个大常数下做微调。4.2 为什么“越设计越复杂”往往就是天算在起作用系统设计者经常掉进一个难以察觉的陷阱当系统开始出现波动第一反应是增加规则去压制波动规则导致新的适应行为于是再增加新的规则。如此循环系统越来越复杂稳定性却越来越差。这种“越设计越复杂”的模式本质上是设计者在和天算拔河。他们想通过精细化控制改变那些根本不由他们决定的宏观结果。比如在物流场地里无论算法怎么优化路径场地的物理总面积、门禁口数量、车辆转弯半径都是固定的这些硬约束构成了系统的“物理天算”企图通过增加控制策略绕过这些约束结果只能是策略数量增加、物理天花板却纹丝不动。更合理的做法是停下来先识别哪些是“不可设计的层”。把不可设计层当成预算约束或边界条件然后把设计的精力转移到可以做局部调整的地方。就像冲浪者不会试图改变海浪的方向而是等着浪来时调整自己脚下的位置。这不叫消极这叫对一个更大系统规律的基本尊重。4.3 项目里识别“天算”信号的几个线索既然天算这么重要怎么在具体项目里识别它我总结过几个出现频率很高的信号。一个是反直觉的周期。无论你怎样调参系统都会出现固定节律的波动比如午高峰、月末峰值、季度考核周期。这说明宏观节律在主导结果计算层的参数只影响局部形状。另一个是衰减效应。每次优化带来的边际收益越来越小第一次优化可能提升百分之二十第二次只有百分之五第三次几乎没有变化。这时候系统很可能已经逼近物理或生态极限再加大投入也只是在极限线上摩擦。还有一个是模式转移。你压制了某一个问题它却变成另一种更隐蔽的问题出现。例如提高了分拣速度质检漏检率上升缩短了排队时间投诉率反而增加。这种位移说明你并没有改变系统底层规律只是把压力推到了另一个节点。最后是边界僵化。无论投入多少资源某个关键指标都停留在一个极限值附近像一堵看不见的墙。出现这些信号时就不要再纠缠计算层的参数和算计层的激励策略了该考虑是不是有更大的规律在起作用。5. 三“算”协同一张实用的判断路线图前面说了很多理论层面的东西这一节讲讲怎么落地。我有一套实际项目里反复用过的思路本质上就是三张清单和三道门先拆问题再定策略最后验证。5.1 先把问题拆成三个区间可控、可博弈、只能顺应没有什么问题是一上来就能“全面优化”的。拿到一个问题第一件事永远是分类拆成三个区间。第一类是可控区间。机器能准确感知、能形式化建模、输出可被验证这一类问题放给计算层处理适合做定量优化。第二类是可博弈区间。问题中涉及有自主目标的人或组织各方会基于自身利益做出策略性调整这类问题放给算计层适合做机制设计而不是纯计算优化。第三类是只能顺应区间。问题背后有物理规律、生态承载力、市场长期趋势这些不可直接调控的大尺度约束这类问题放给天算层能做的只是适配、避险和等待时机。分类的过程通常会颠覆团队的认知。有一次我和一支技术团队做方案评审他们花了两周时间优化一个推荐策略的参数结果发现核心瓶颈是用户对新推荐位的不信任这是一个典型的可博弈区间问题。参数优化优化到天只是在可控区间里打转完全没触及真正的瓶颈。最容易犯的错误是把“只能顺应”的问题当成“可控”问题来解决用加规则、加控制的方式对抗客观规律结果就是白白消耗资源。正确的态度是不跟地心引力较劲而是顺着它设计出椅子、楼梯和电梯。5.2 落地五步核查表把你的方案过一遍这三层我会用一张五步核查表来验证一个方案是否真的覆盖了三层“算”。第一步划定形式化边界。明确自己要“计算”的问题边界哪些变量进了模型哪些数据可信哪些输出可以验证哪些变量明确不进入模型。这一步是防止目标失真和语境失全的前提。第二步设定博弈坐标。把方案放进利益相关者网络中逐个问谁有动机偏离方案偏离端口在哪里方案释放了什么信号诱使偏离是不是某些规则写着“请配合”但激励结构写着“请对抗”第三步剔出天算变量。把暂停不了、调节不了、只能接受的约束条件单列出来明确标注为边界而非目标。比如场地总面积、总通行时间、人的注意力上限这些都是天算变量不要混进优化目标里。第四步设计三层接口。为计算层设计标准化输入和可回滚输出为算计层预留选择通道和反馈通道为天算层设定缓冲余量和止损阈值。三层接口缺一不可。第五步建立验证闭环。至少准备两套对照方案一套是不做任何算计设计的纯计算方案一套是加入了博弈缓冲和天算适配的方案用实际运行数据验证哪套更能扛住波动。这张表看起来简单真做起来往往需要好几个来回才能填完整。但每次填完方案质量都会有肉眼可见的提升因为它是逼着你把视角从“算法内部”抬到“系统全局”。5.3 用对照实验验证“三算”框架一组真实的实验数据我们接着讲仓储项目的第二轮实验。当时我们按三算框架把方案拆成了三组来做对照。A组是纯计算方案路径最短、时间最短所有决策由算法统一调度。B组在A组基础上加入算计设计允许操作员有限改派增加窗口授权同时调整绩效公式让个人顺手的行为和系统目标一致。C组在B组基础上再加入天算适配根据午间人流节律和场地物理瓶颈做时段错峰把“总吞吐量上限”作为规划硬约束。两周实验结果差别明显。A组异常事件和高峰拥堵率最高操作员抵触情绪也最明显。B组在A组基础上降低了约三成异常事件主要是改派授权和绩效调整之后人为绕行减少了。C组在B组基础之上又降低约两成违规绕行和高峰拥堵因为错峰策略让人流和设备流不再互相踩踏。这个对照实验给我的印象非常深。它说明每一层“算”都在弥补其他层的盲区多花一点点功夫把三层同时纳入得到的不是某一个指标的提升而是系统整体韧性的提升。所谓“整体韧性”就是面对波动不失控、面对偏离能纠偏、面对物理边界不硬撞的能力。6. 最后分享一点我的个人体会写到这里我想起那个AGV项目后来是怎么收尾的。我们最终没有选择单一的“最优策略”而是把调度参数改成了时段敏感模式给工人保留了有限改派的通道甚至允许低峰时段人工完全接管巷道。设备利用率其实略有下降但整体吞吐量反而稳定上涨。我自己的感受是所谓的计算、算计、天算不是什么哲学口号而是三个必须同时出现在系统设计文档里的检查项。计算再重要也不能忽略人会用自己的行为投票算计再精巧也不能忽视更大尺度的规律会把小聪明折算成成本天算再硬也需要前两层去创造局部空间在约束里找到生存缝隙。后来每一次拿到新项目我都会先问自己一句我现在算的到底属于哪一个层级如果连这个问题都答不上来那后面做的所有优化很可能只是在自己的想象里自嗨。先把“算”分层再来谈怎么算这句话值得写进每一个系统设计评审的第一页。