同一个模型，接入不同的业务本体与 Harness，为什么像两个完全不同的员工
Agent 产品的差距越来越不只在模型参数，还取决于业务本体是否定义了真实世界，Harness 是否让模型安全行动。下一批机会，可能来自补齐这两层，而不是只等待更大的模型。
凌晨两点，一个代码 AI Agent（智能代理）收到任务：把旧服务迁移到新框架，并保证现有测试全部通过。
在第一个产品里，它读完代码后给出一份迁移建议，列出二十多个步骤，然后停在那里等工程师动手。在第二个产品里，它创建分支、修改文件、运行测试，看到报错后继续修正，最后提交一份带测试记录的变更。
底层模型没有换，结果却像换了一个人。
模型决定推理上限，业务本体定义它面对的世界，Harness 决定它能否行动，治理机制保证行动可控。下一代 Agent 产品的突破，未必都来自更大的模型，也可能来自把这四层真正连接起来。
模型会什么，和用户能得到什么，中间隔着一层产品
模型可能已经能够阅读大型代码库、调用工具、拆解任务、比较结果，甚至在失败后修正方向。但如果产品只允许它在输入框里回答文字，这些能力就只能停留在演示里。
传统软件的产品设计主要负责把功能展示给人。Agent 产品还多了一项任务：给模型提供环境，让它能够采取行动、看到反馈并继续推进。
这层行动环境通常被称为 Harness。它包括系统提示词、工具、权限、上下文、运行环境、验证方式和人与 Agent 的交互界面。
但只给工具还不够。模型即使可以查询数据库，也未必知道“客户”“订单”“合同”“退款”之间是什么关系，更不知道一个订单处于什么状态、什么条件下允许退款、哪类客户需要额外审批。
业务本体：让 Agent 知道自己身处什么世界
业务本体（Ontology）不是给模型再塞一批文档，而是把企业中的对象、关系、状态、规则和动作定义清楚。
例如，客户拥有订单，订单关联商品与合同；订单可以处于待支付、已发货或已完成状态；不同状态允许执行的取消、退款和补偿动作并不相同。
没有本体，Agent 得到的是零散文本和字段，只能依靠临时上下文猜测业务含义。有了本体，它看到的才是一个结构化、持续更新、可以操作的业务世界。
这四层可以概括为：
配图一：模型、本体与 Harness 如何形成行动闭环
其中任何一层接近于零，最终产品能力都会被卡住。模型再聪明，没有业务世界就容易答非所问；本体再完整，没有行动接口也只是静态地图；工具再丰富，没有治理就无法进入高风险业务。
Product overhang：能力已经到了，产品还停在过去
访谈中提到一个重要概念：Product overhang，可以理解为“产品尚未兑现的模型能力”。
早期 AI 编程产品主要做单行补全、多行补全和只读问答。即使模型已经能写完整函数或文件，产品仍然把它限制在“建议者”的位置。
Claude Code 的变化，是把模型放进终端，允许它读取、写入、运行和验证。产品没有重新训练模型，而是换了一种让能力表达出来的方式。
这也是很多 Agent 产品的机会：模型已经可以完成一段工作，但行业仍把它包装成一个聊天助手。
Hobbling：越复杂的脚手架，未必越聪明
模型能力不足时，团队会增加固定步骤、路由器、提示词和中间 Agent。每一层都在解决一个真实问题，但新模型发布后，这些补丁可能变成新的限制。
一个本来可以自己规划的模型，被要求严格执行十个步骤；一个本来会选择工具的模型，被路由器提前分配到错误路径；一段本来清晰的任务，被几千字系统提示淹没。
产品越努力“帮助”模型，模型反而越难发挥。这就是 hobbling。
解除束缚，不等于取消安全
Unhobbling 最容易被误解为“把所有权限都给 Agent”。真正应该删除的，是过时的能力补丁，而不是权限、日志和责任边界。
一个能够修改代码、发送邮件或支付的 Agent，至少要具备：明确身份、最小权限、预算上限、关键动作确认、完整日志和可回滚结果。
能力越强，错误传播得越快。安全不是妨碍 Agent 的脚手架，而是让它进入真实业务的门票。
哪些公司可能成为赢家
最可能受益的，不只是拥有模型的公司，还包括三类产品：能够把行业对象和规则沉淀成业务本体的垂直产品；能把工具、权限和验证做成基础设施的平台；能找到模型潜在能力并做成稳定体验的创业团队。
压力更大的，是只在模型外面包一层聊天界面、没有业务对象与状态、没有工作闭环，也无法对结果负责的产品。
配图二：通用聊天助手与业务 Agent 的差别
本体也会成为一种更耐久的产品资产。模型可以替换，工具接口可以升级，但企业长期积累的对象定义、业务关系、异常规则和责任边界，很难从公开模型中直接获得。
团队现在可以做什么
选择一个高频任务，分别让裸模型、当前产品和删减后的 Harness 完成；记录成功率、耗时、人工接管点和失败原因；找出哪些流程真正在提供价值，哪些只是历史遗留。
同时做一次本体盘点：任务涉及哪些业务对象，它们之间是什么关系，有哪些状态变化，哪些规则决定允许执行的动作，谁对异常结果负责。
如果团队无法用清晰结构回答这些问题，就不应该期待模型只靠一段长提示词稳定理解业务。
不要从“还能再加什么”开始，而要先问：“如果删掉这一层，模型会不会做得更好？”
下一代产品，可能从一次删除开始
模型公司负责提高智力上限，产品公司负责定义业务世界，并把智力变成可靠结果。
这两件事并不相同。一个更强的模型，放在错误的产品里，仍然只能给建议；一个更懂能力激发的产品，可以让已有模型完成过去没有人想到的任务。
产品的任务不是替模型完成思考，而是给模型一个可以理解的业务世界、一套可以行动的工具，以及一条能够验证和追责的结果链路。