所谓harness，我的理解是只要模型的context不是无限长且没有质量和理解上的损耗，工程上的优化就永远是有必要的，类似于在早期深度学习或者更早的机器学习的年代，无论使用什么样的模型，规则永远是必要的，只不过当年的规则解决的是冷启动和长尾的问题（这两个问题在现在可以说基本已经被解决了），现在工程上的约束解决的是non-deterministic的抽卡带来的稳定性问题，包括不限于模型对于工具的调用的精准程度，对于业务场景的理解深度，以及模型输出对于下游的可用性。
工具的调用有两种情况，一种是对现有工具的hack，比如说现有的一个SaaS产品或者一种工具型产品，通过API或者浏览器自动化，让模型去代替人进行操作，这种情况下是模型去适应工具。另外一种情况是让工具适应模型，也就是现在常说的面向模型的设计。现实生活中，特别是在企业场景下，绝大多数都是第一种情况。这样会遇到的一个问题是，现有的工具的交互设计和信息架构是为了人操作的方便，根据业务场景去划分功能，导致很多功能之间有重叠，但这个冗余是模型经常分辨不了的
举个例子，一个数据平台可能会存在多个跑数的功能，有的是为了临时跑数，通常只支持查询，不支持定时调度，而另外的功能会在跑数的基础之上，支持任务的调度和其他更复杂的参数设计。对于平台来讲，这是两件事情，因为是两个应用场景，所以很自然的分成两个功能去做，但是对于模型来讲，它很难分辨这个跑数是临时的还是定时要执行的，或者说这个分辨对他来讲没有意义。这个时候，如果遵循现有的产品设计，就很容易调用错误。这里其实涉及到了任务的边界，调度这件事情到底是交给平台来做，还是交给模型应用层来做？如果是采用后面这种方案，就涉及到了之前提到的削峰填谷是不是能够被解决。这跟传统的机器学习分类任务的意图识别其实非常类似，分类的设计原则也同样适用于这里工具的设计，如何做到MECE很考验产品设计的水平。长远来看，现有的这些产品未来是否面临着工具化调用的改造，这个改造对现有的定价和其他的商业模型有什么影响？与其叫喊SaaS已死，不如思考一下这些更具体的问题。
对于已经定义好的工具，没有办法轻易的去改动它的接口设计，那这种情况下，模型是不是能够稳定高效的准确判断用什么工具，以及工具怎么用，这不仅是一个技术的问题，也是一个业务的问题。如果说模型必须以枚举所有可能的方案，一个一个的试错来找到正确的方式，不仅造成了token的大量浪费，也造成了没有意义的时间浪费，而时间成本的减少，在绝大多数情况下是模型产品的最大卖点。
在业务场景的理解方面，其实也不是什么新鲜东西，所有的SaaS的销售当中，最重要的一环就是基于客户的实际使用场景来做功能的适配，这里也是一样的。模型或者Agent的本身对于业务场景的理解直接决定了它是不是真的能产生价值。
公有云上的模型能够访问到的都是公域的数据。但是在企业场景下，或者说在所有的模型可以发挥作用的场景里，私有的数据才是能产生最大附加价值的地方。它们的数量庞大可以带来规模效应，这些自有的数据的拥有者和生产者也有更强的付费能力。但是怎么让公有云的模型学习到私有的数据呢，RAG和微调算是两个流派，哪个好用当前没有一个定论。但无论用哪一个，考虑到企业场景下的数据敏感程度和成本管理，基于闭源模型产品的自部署和开源模型的部署和微调应该是非常有想象力的，且他们首先要解决的一个问题就是如何突破模型上下文的限制，让模型掌握足够多的企业内部知识，并且可以稳定的输出。和传统的机器学习类似，迭代速度会是一个问题，类似之前的模型加规则混合模式，以后会不会也出现一种微调加召回混合模式？进一步想，相关的infrastructure会产生怎样的变化，从管理学的角度而言，对组织行为会有什么样的影响，真的如现在很多人所说，大的组织会因为变革不够迅速而遭到颠覆吗？还是说这个事情纯属just for fun不会对最终盈利有特别显著的正向影响?
即便不会产生根本性的变革，模型的产出是否在一个非常基本的程度上可用?在我的这个场景里，以我自己为例，工作中同时在用两个数据平台，一个用来做数据开发，另外一个做看板，原本如果我有一个数据需求，我需要写需求文档和做需求评审，完了交给数据仓库和BI分工串行开发，现在我通过Claude Code + CDP代替了绝大部分的单纯的执行层面的工作，可以一个人哐哐干完所有事情。但问题是，从整个需求或者整个项目的进程而言，真的变快了吗？实不相瞒，我觉得没有。当然现在好的地方是相比之前少的很多人之间的摩擦，因为一个人干活不需要和人沟通。但也正因为缺少了这个沟通，虽然很快的冷启动，但是通常是很不完善的，需要频繁的“迭代”，因为这个改动通常涉及到中间表，包括改表结构，甚至删表重建，产生了在旧的流程下不太会发生的变动，这些在我看来是资源的浪费。特别是看板平台的自动化可以说是没什么价值。一方面因为这个平台的操作频率很低，自动化的ROI低到不如手动操作，还能给减少上下文的污染程度，另一方面，自动化的制作看板本身跟通过模型去完成数据的分析是相违背的。如果说还是要用模型去读取看板的数据，那我为什么不去掉看板直接去读取底层的表来做计算呢？
言而总之，跟所谓传统的产品设计一样，还是要从解决什么问题，用户是谁，在什么场景下使用，这几个最核心的问题出发来决定需要实现什么和怎么实现，外加使用的人数和频率直接决定了是否值得投入资源。成本当然也是一个很重要的因素，但现阶段模型软硬件的成本随着技术的进步而降低是一件可预期的事情，所以除非成本高到完全不能承受，不然不用太考虑。当然，不做任何判断，直接上手也是可以的，因为一个新的范式的出现，未必是对于旧范式的替代，也有可能在研究的过程中发现了一些之前不存在的场景或者做事方式。至于实现的过程，现在还没有任何固定的套路可言，大体来讲还是根据需求，从最最简单的聊天框开始，有解决不了的问题再寻找更复杂的方案，比如说Claude Code，还有解决不了的问题就再找更多工程优化的方案，直到能够解决足够多的问题，达到足够的可用性。