大模型已经能够理解复杂问题、生成代码、调用工具，甚至独立完成多步骤任务。但进入企业真实业务时，很多 Agent 项目仍然停留在 Demo 阶段。
Agent 究竟是能力不够，还是被迫承担了太多原本不属于自己的复杂度？
一、从 AI 问数开始
假设用户问：“上个月销售额是多少？”
看起来很简单：大模型理解问题，生成 SQL，查询数据库，返回结果。
但首先，什么叫销售额？
是合同金额、订单金额、发货金额、开票金额，还是实际回款？按照哪个日期统计？是否包含取消、退货和变更的订单？金额是否含税？
再往下，还要知道这些指标涉及哪些业务对象，分布在哪些系统里，数据表如何关联，哪个来源可信，以及当前用户有权查看哪些数据。
这些问题都没有解决之前，生成 SQL 只是任务中很小的一部分。
AI 问数的难点，不只是模型能否生成正确的查询，而是企业能否明确表达自己究竟在问什么，以及答案应该如何计算。
二、上游没有处理的复杂度，最终都交给了 Agent
沿着这个例子往前追溯。
业务需要定义销售额的含义、统计范围和计算规则；产品需要将这些定义组织成可复用的指标与分析能力；技术需要承载数据模型、计算逻辑、数据关联和权限控制。
如果这些工作没有完成，到了 Agent 这一层会发生什么？
我们开始在 Prompt 中解释业务口径，在 Context 中塞入数据库 Schema、指标文档和特殊说明，用 Memory 保存历史查询经验，再通过工具调用、SQL 校验、错误重试来提高成功率。
这些工程能力当然有价值，但它们正在处理的问题，并不完全属于 Agent 自身。
业务、产品和技术没有消化的复杂度，被转化成了 Agent 的上下文管理、推理与执行复杂度。
在 Demo 中，我们可以提前准备数据、限定问题范围、提供准确的 Schema。但真正投入日常运行，业务规则会变化，指标口径会调整，数据与权限也会持续更新。
如果每个 Agent 都需要重新理解一遍业务定义，每次变化都要修改大量 Prompt 和上下文配置，那么随着 Agent 和任务数量增加，重复定义、不一致和维护成本也可能不断增长。
这正是《从业务、产品到代码，三张可互算架构图》希望解决的问题：让业务定义与产品、技术实现建立明确联系，而不是每到下一层就重新解释一遍。
三、Harness 越来越复杂，环境却没有变好
今天很多 Agent 工程实践，围绕 Harness、Context 和 Memory 展开：如何组织任务、调用工具、压缩上下文、保存记忆、恢复执行。
但这里混合了两类不同的问题。
一类属于 Agent 自身，例如当前计划、临时假设、中间结果、历史经验和执行状态。
另一类属于业务环境，例如客户、订单、指标、规则、权限以及它们之间的关系和当前状态。
主体的认知状态，不等于环境的运行状态。
Agent 可以记住自己上次如何分析销售数据，但企业的销售额定义，不应该只存在于某个 Agent 的 Memory 中。规则发生变化，也不应该要求所有 Agent 分别更新自己的理解。
如果这些稳定、共享的业务信息能够由环境持续维护，Agent 就可以按需读取和使用，而不必每次从零推断。
Harness 仍然负责连接智能与环境、组织执行和处理异常，Context 与 Memory 仍然有自己的作用。但它们不必代替企业维护整个业务世界。
这也是我在《Context Engineering：一场草稿纸管理工程》和《把 Agent Harness 放回数字化背景中理解》中反复讨论的边界问题。
Agent 需要处理多少复杂度，不仅取决于任务本身，还取决于环境已经替它承载了多少。
四、别只顾着造全地形车，修条路吧！
今天很多 Agent 工程实践，就像在研发全地形车。
环境混乱，就增强适应能力；规则不清，就增加上下文；容易迷路，就升级 Memory；执行不稳定，就强化 Harness。
但如果每天都要在同一片泥地里来回跑，为什么不考虑修一条路？
修路需要投入，但一旦建成，所有车辆都能使用，新增车辆也不必重新克服相同的障碍。
修路本身甚至可能更耗油：挖掘机和压路机消耗的燃料，不是为了完成某一次运输，而是为了改变此后许多次运输的条件。同样，评价 Agent 的任务执行成本和共享业务环境的建设投入，不能只看单次任务的消耗。
企业 AI 面临的也是如此。
甲方同样困扰于复杂的业务环境、割裂的系统和大量人工协调，只是未必意识到，除了不断增加工具和人力，还可以重新建设业务环境。
对于拥有业务环境控制权的企业，修路是一种值得考虑的系统级优化。对于没有这片“地”的 ToB 服务商，则需要争取参与环境建设的机会，而不只是为每个客户反复定制适应泥地的全地形车。
当然，全地形车仍然有价值，真实世界总有道路无法覆盖的地方。
但如果道路可以建设，我们就不必把所有复杂度都交给车辆处理。
别只顾着造全地形车了。修条路吧！