DeepSeek 开源了 Harness，定位是“Agent 工作台”。一句话：Model + Harness = Agent，模型之外的所有工程活，它全包了。 OpenAI 把 Codex 的底层 Harness 全面开源，Apache 协议，开源后热度一路蹿升。 DeepSeek 还上了一个实验性的视觉模型，DeepSeek-V4-Flash-Vision-Exp，能看图。 这三件事让我想到一个更具体的问题：当看图成本开始下降，Agent 的执行框架逐渐成熟，检测软件还需要具备什么，才能真正参与到 AI 驱动的检测流程中？ 回答这个问题，得先把检测工程师每天面对的难处拆开。我看下来，是三道坎。
第一道坎：看懂图纸 手边有张焊接件的图。上面标着基准，几个孔的位置度，一个斜切口。看着稀松平常。 很多人以为，检测就是照着图纸，把数字抄进软件。事情远不止如此。 图纸是一种高度压缩的工程语言。图纸上的每一个符号，都对应着一组需要在三维空间里理解的几何关系。 就说位置度。图纸上写一行：位置度 ⌀0.1 A B C。就这几个字符，但它同时包含了被测特征、理论位置、基准体系和公差判定方式。 真正开始检测前，工程师必须先判断：哪些是基准，哪些是被测特征，哪些尺寸和公差之间存在关联。视图、剖视、引出线和标注之间，还可能互相补充。 图纸写的是“要求”，没有直接写出“软件应该怎么一步步做”。它首先要求工程师完成一次从二维符号到三维意图的翻译。 这就是第一道坎：看懂图纸。难的不是认字，是把分散的标注还原成一个完整的检测目标。 第二道坎：用顺软件 假设第一道坎过了，图纸看懂了，你知道要建基准、评位置度。 图纸看懂后，打开软件。第二道坎来自系统复杂度，熟练度只是其中一部分。 检测软件是大型系统软件。一方面，功能必须足够完整。某个特殊的对齐方式、某个冷门的公差类型、某种少见的拟合算法，缺一个，遇到对应工件就可能卡住。 另一方面，功能越多，人越难掌握。菜单越来越深，参数越来越密，概念之间还相互依赖。一套软件有几百项能力，工程师处理一个具体工件时，真正需要的可能只有十几项，但他必须先找到这些能力，再按正确顺序和正确参数把它们串起来。 因此，“用顺软件”的关键，是让软件能力变得可查询、可组合、可验证。AI 要知道当前有哪些工程对象、哪些操作可用、一次操作产生了什么结果，不能仅停留在识别按钮位置。 回到刚才的位置度例子：理解图纸只是第一步。真正落到软件里，还要建立 A、B、C 三个基准，确定它们如何在空间中约束零件；提取被测孔并拟合圆柱，决定拟合范围是否避开倒角和噪声；根据基本尺寸确定理论位置，再计算实际偏差。如果后面还有最大实体要求，还要把补偿规则交给确定性算法处理。 图纸上的几个字符，最后要变成一条有顺序、有参数、能检查结果的操作链。软件功能越多，这条链越需要有人或智能体负责组织。 第三道坎：从头再来 假设前两道坎都过了，这个工件检测完了，报告也出了。 下个月，又来了一个同类型工件。公差差不多，基准差不多，流程几乎一样。 你会发现，导入、建基准、对齐、提特征、评公差，还是要重新做一遍。因为上次的经验长在人的脑子里，没有变成软件可调用的资产。换个人来，或者自己忘了关键参数，又要重新摸索。 这就是第三道坎：复用。检测知识没有固化下来，每个同类工件都在重复造轮子。 三道坎，本质上是同一个问题 三道坎，表面上一个是理解工程语义，一个是组织复杂软件能力，一个是复用已有经验。往底下一看，都是检测领域知识如何进入软件的问题。 过去，这套知识主要靠“做”来学、靠“人”来传。图纸如何展开成检测方案，软件功能如何组合，哪些参数在什么工件上有效，大量细节只存在于个体经验里。 一方面，检测离不开人的判断；另一方面，任何人的知识和注意力都有边界。软件能力越来越多，工艺经验越来越细，一个人不可能同时记住所有入口、规则和例外。 检测智能体要把工程师从“记菜单、串步骤、重复操作”的瓶颈中释放出来，让他们把精力放回工艺判断、风险确认和结果签字。最终判断和责任仍然属于工程师。 怎么做：让 AI 理解、编排、调度、沉淀 接下来，分工应该很清楚：AI 负责解析检测信息，形成对检测目标的候选判断和检测方案，编排任务、调度软件、读取执行结果，并协助沉淀工作流；工程师负责确认关键假设、处理异常情况和对最终结果负责。 这里有一条前提：AI 负责认知和组织，确定性内核负责计算，两者的边界必须清楚。 怎么理解目标？ 这里的“目标”，指的是这次检测要检查什么、依据什么判定，以及完成判定需要哪些输入。它包含被测特征、基准关系、理论尺寸、公差要求和最终需要输出的结果。 AI 首先要把几类信息放到一起理解：用户提出的检测要求、图纸中的标注、当前工程里的 CAD 和测量数据，以及软件当前已经建立的对象。视觉模型负责整理图纸和界面中的信息，工程知识负责解释这些信息之间的关系，软件状态则决定哪些内容已经具备、哪些内容仍然缺失。 以位置度为例，目标不是简单识别出“这里有一个 ⌀0.1”。更完整的目标应该包括：评定哪个孔，使用哪些基准，理论位置如何确定，适用什么公差规则，需要哪些测量特征，以及最终要输出哪些偏差和判定结果。 把这些信息组织成检测目标，需要领域知识参与。基准体系如何约束零件，基本尺寸如何确定理论位置，最大实体要求如何影响判定，哪些测量特征适合支撑某项公差，这些关系都应该沉淀为可检索的规则、模板和案例。视觉模型负责整理信息，领域知识负责解释关系，检测软件负责校验参数和执行条件。 AI 输出的应该是一份带依据的候选目标：每个判断来自哪里，置信度如何，还缺什么信息，都要记录清楚。涉及基准选择、公差规则和最终判定的关键内容，由工程师确认后再进入后续编排。 理解阶段的输出，是一份经过确认的检测意图：明确检测对象、判定依据、所需输入和待解决的问题。接下来，任务编排要做的，就是把这份检测意图组织成一条可执行、可验收的流程。 怎么编排？ 有了检测意图，下一步要解决的是流程组织。编排解决的是任务应该怎样排列、彼此如何依赖，以及每一步用什么结果作为继续执行的依据。检测流程由一组有前后依赖、输入输出和验收条件的任务组成。 以位置度检测为例，流程可能是：导入 CAD 和测量数据，确认参考模型与测量模型，建立基准和坐标系，提取被测孔，计算理论位置，评定位置度，最后生成报告。后一步要使用前一步产生的对象和结果，顺序不能随意调换。 因此，每个任务都需要明确三件事：执行前需要什么，执行后产生什么，什么条件下才算完成。建立坐标系之后，要确认对齐对象确实存在；提取圆柱之后，要检查拟合结果是否有效；评定公差之后，要读回测量值、偏差和判定结果。状态没有通过验收，流程就应该停下来等待处理。 人工确认也应该放在流程节点中。导入文件、修改基准、删除对象、改变最终判定等高风险步骤，需要工程师确认后再继续；只读查询、能力内省和结果汇总，可以自动完成。这样，人的判断进入关键节点，机器负责执行已经确认的步骤。 怎么调度？ 任务流程编排完成后，调度进入执行阶段：它按照任务的输入、依赖和验收条件，调用 Inspect 的能力完成当前步骤，并把执行结果反馈给流程。我们的选择是 Python。 Inspect 把模型、特征、对齐、比较、检验和报告等能力组织成 Python API。外层智能体提交 Python 脚本，代码在 Inspect 内部执行，结果再以结构化数据和日志返回。 这里的“结果”需要包含明确的对象状态、几何参数、偏差统计和公差判定，不能只返回一段自然语言或一张界面截图。截图可以补充空间分布和界面上下文，但确定性的数值结果必须单独保留。 为什么选 Python？它可以同时表达工程对象查询、几何特征拟合、对齐方法组合、统计量计算和插件生成。更重要的是，这些操作共享同一套工程对象和状态，前一步创建的基准、特征和对齐，可以直接成为后一步的输入。用脚本描述流程，比用鼠标描述流程可靠得多。 但任意代码执行能力也意味着真实风险。当前验证版本适合本机、受信环境，不应该把它直接描述成已经具备完整安全体系。产品化至少要补齐：仅本机监听、短期令牌、请求审计、执行超时、并发控制、危险模块限制，以及高风险操作前的人工确认。 安全不是一句“有沙箱”就结束了。更合理的演进方向，是同时保留灵活的脚本入口和稳定的领域 API：前者用于快速探索和能力补充，后者用于生产工作流和权限控制。 我们在实验室验证了一遍 为了确认这条路在工程实践中可行，我们在实验室环境里跑了几组代表性任务，用的都是自建的测试工件，不涉及任何客户项目。 一组是完整的 3D 比较流程：导入 CAD 参考模型，导入扫描测量模型，执行最佳拟合对齐，创建 3D 比较，读取合格率和偏差统计，最后生成报告预览。 一组是几何特征构建：在模型上一次锚定多个点，由软件拟合成平面；再以同样的方式依次构建三个方向的平面，用它们建立坐标系并完成对齐。 一组是工程诊断：让智能体读取一个已完成检测的工程，遍历其中的模型、对齐、特征和检验结果，判定某项角度检验超出上公差。 这三组任务覆盖了从模型导入、几何构建、坐标对齐，到比较、检验和结果解释的完整链条。验证的重点在于：AI 能否在每一步之后读回状态，并据此决定下一步。 这些任务里，AI 没有计算任何几何结果。点怎么拟合成平面、三维偏差怎么算、角度是否超差，全部由 Inspect 的确定性内核完成。AI 负责选择合适的能力、组织参数、执行操作、读回状态和解释结果。 验证过程中也发现，自动化能否稳定复现，取决于模型能力，也取决于交互状态能否读回、对象是否有稳定标识、结果是否足够结构化。这些都是下一步需要继续完善的工程问题。 怎么沉淀？ 一条流程跑通之后，问题还没有结束：怎样把它留下来，供下一次相似任务直接调用？答案是把已经跑通并被工程师认可的流程，变成可复用资产。 我们的做法是把业务流程固化成 Inspect 插件。一条跑通的流程，连同入口脚本、插件描述和图标，一起纳入软件。之后遇到同类任务，先从插件列表中检索和匹配，符合条件就直接复用，不必让 AI 从零生成整段代码。 插件库的价值取决于每个流程是否具备清晰的适用条件、参数说明和验证记录。智能体需要按任务检索和匹配插件，执行前后进行状态校验，结果经过工程师确认后，才能形成持续积累。 经过这些环节，插件库才能成为可检索、可验证、可演进的检测资产。模型可以换，Harness 可以换，但经过验证的检测流程和领域数据会留下来，这才是更长期的积累。 四个动作，一条完整的路 四个动作其实很清楚：理解检测目标，编排检测任务，调度软件能力，沉淀验证过的流程。 它们串起来，才形成一个真正可工作的检测智能体：能够把工程意图转成检测流程，把流程变成软件动作，再把经过确认的经验留下来。 老师傅脑子里那套“怎么看、怎么做、怎么判断、怎么复用”的知识，才有机会逐步变成软件里可执行、可验证、可积累的资产。 最后一条线 基准建得对不对、拟合范围取多大、对齐方式是否合理，最终都会影响一批零件的判定。AI 可以提供建议、组织流程和解释结果，但测量值、公差计算和最终判定必须回到确定性内核。 最终证据也应该是结构化、可追溯的计算结果：拟合统计、偏差、公差上下限、合格率和其他测量数据。 写在最后 目前看，工业检测智能体真正要解决的，是建立一套可靠的关系：领域知识能被检索，软件能力能被调用，执行状态能被验证，成功流程能被沉淀，最终数值仍由确定性内核负责。 视觉模型可能看错，规划可能走偏，API 也会暴露新的设计问题。把这些问题一轮轮跑出来、修掉，比做一个看起来很聪明的演示更重要。 我会继续做，继续验证，继续写。想法会变，被打脸也认。写下来，是想让这个过程有迹可循。 如果你也在做工业软件的智能化，希望这些坑和路，能给你省点时间。
夜雨聆风