从推理经济到物理智能：智能体系统工程实践

一、重新理解人工智能的价值链：从模型能力到任务交付

人工智能应用正在经历一个重要变化：系统不再只回答问题，而是逐步参与信息检索、方案制定、工具调用、流程执行和结果验证。对于企业而言，这意味着技术建设的目标不能停留在“接入一个模型”，而要转向“稳定完成一类业务任务”。

这一变化可以从三个层面理解：

第一，计算需求正在向持续运行的推理服务扩展。模型训练仍然重要，但当智能能力被嵌入客服、研发、办公和生产流程后，推理会成为长期、反复发生的资源消耗。

第二，软件的交互方式正在变化。过去，用户需要理解菜单、字段和操作步骤；在智能体模式下，用户可以描述目标，由系统组织后续操作。不过，目标描述并不能自动替代权限校验、业务规则和事务管理。

第三，智能能力正在从数字空间延伸到物理环境。系统不仅需要理解文本，还需要处理图像、空间状态、动作反馈以及现实世界中的不确定性。

因此，评估智能系统不能只看模型规模或理论算力，而应同时回答四个问题：能否完成任务，完成得是否可靠，成本是否可接受，风险是否可控制。

二、词元经济：为什么生成速度不等于业务生产力

1. 词元是计算计量单位，不是业务价值本身

词元是模型处理序列时使用的基本单位。一个词元可能对应一个字、词的一部分、标点或其他编码片段，具体划分取决于编码方式。因此，不能把词元数量简单等同于中文字数，也不能认为输出越长，交付价值越高。

在生成式系统中，词元吞吐率可以反映部分服务能力，但企业真正关心的往往是：

• 完成一次有效任务需要多少资源；
• 用户等待多久才能获得可用结果；
• 输出是否正确、完整并符合业务约束；
• 是否需要人工修改或重新执行；
• 高并发时能否保持稳定的服务质量。

一个每秒生成更多词元的系统，如果经常答非所问、调用错误工具或触发多次重试，最终可能比生成速度较慢但准确率更高的系统更昂贵。

2. 用“有效任务成本”替代单一生成成本

对企业应用而言，更合理的成本口径是：

有效任务成本＝统计周期内的任务相关总成本÷通过验收的任务数

其中，任务相关总成本应覆盖模型推理、检索、工具执行、存储、网络传输、失败重试、安全检查及人工复核等开销。评估长期投入时，还应按合理周期分摊数据治理、模型适配和系统建设费用。

这一口径能够揭示一些常被忽略的问题。例如，增加一轮结果校验可能提高单次推理费用，却减少错误返工，从而降低有效任务成本；反之，压缩模型或缩短上下文虽然降低了单次调用成本，也可能因准确率下降而增加总体支出。

因此，成本优化的目标不是“每次调用都最便宜”，而是“在质量和风险约束下，每个有效结果的代价最低”。

3. 推理服务要区分不同阶段的瓶颈

典型的自回归生成过程，可以粗略分为输入处理与逐步生成两个阶段。

输入处理阶段需要处理已有上下文，适当的并行计算通常有助于提高效率；逐步生成阶段则存在前后依赖，往往对内存带宽、缓存管理和请求调度更加敏感。具体瓶颈还取决于模型结构、上下文长度、运行精度及软硬件实现。

因此，不能用单一的峰值计算能力预测真实服务表现。实际评估至少应覆盖：

• 首个输出片段到达前的等待时间；
• 持续输出阶段的生成速度；
• 请求完成时间及其尾部延迟；
• 不同输入长度下的吞吐变化；
• 并发增长时的成功率和资源占用；
• 长任务与短任务混合运行时的相互影响。

对于交互应用，首个输出的等待时间通常影响使用体验；对于离线批处理，总吞吐和单位成本可能更重要。两者应采用不同的调度策略和服务目标。

三、从模型到智能体：真正需要的是可控运行环境

1. 智能体不是“模型加循环”

一个能够调用工具的模型，并不天然构成可靠的智能体系统。完整系统通常需要具备以下能力：

• 理解任务目标及完成标准；
• 获取必要的业务上下文；
• 将目标拆分为可执行步骤；
• 在授权范围内调用工具；
• 根据执行反馈调整后续行为；
• 验证结果，并在必要时终止或升级处理。

可以用下面的流程表示：

用户目标 → 身份与权限检查 → 上下文获取 → 计划生成 → 受控执行 → 结果验证 → 交付或人工接管

关键区别在于：模型负责提出候选决策，运行环境负责约束这些决策能否执行。

例如，模型可以判断某项退款申请可能符合条件，但最终能否退款，应由业务规则、账户权限、额度限制和审批机制共同决定，而不是仅由生成文本决定。

2. “智能体操作系统”更适合被理解为架构类比

将智能体运行环境称为一种新型“操作系统”，可以帮助理解其资源组织和任务调度作用，但不能据此认为它已经替代传统操作系统。

传统操作系统管理进程、内存和设备；智能体运行环境主要协调模型、工具、上下文、任务状态和权限。它依然依赖底层计算、网络、存储及安全基础设施。

从工程角度看，这类环境通常需要五个核心模块：

任务编排层。 管理任务状态、步骤依赖、超时、重试和终止条件，避免执行流程无限延伸。

上下文管理层。 组织当前输入、历史记录、业务资料和中间结果，明确哪些信息可信、哪些需要验证。

工具接入层。 为外部能力提供结构化输入输出、权限控制和错误处理，减少模型直接操作底层系统的风险。

策略控制层。 对敏感数据访问、外部通信、资金操作和不可逆动作进行约束。

评估观测层。 记录任务轨迹、模型调用、工具结果、资源消耗和人工干预，支持故障定位与效果分析。

这些模块的价值不在于增加概念，而在于把不可预测的生成行为纳入可观测、可审计的执行体系。

3. 软件不会全部变成自主智能体

不同业务对确定性、响应时间和责任归属的要求不同。规则稳定、流程明确的功能，通常仍适合用传统程序实现；需求模糊、信息非结构化、路径变化较大的环节，才更适合引入模型参与决策。

更现实的架构是混合式软件：

确定性业务内核＋智能决策辅助＋受控工具执行＋人工异常处理

例如，合同系统可以使用模型提取条款并提示风险，但归档、版本控制、权限分配及审批状态转换仍由确定性逻辑管理。这样的分工通常更容易测试，也更便于明确责任边界。

四、开发实践：让智能体具备边界、证据与恢复能力

1. 先定义验收条件，再设计执行流程

开发团队应先明确任务完成的可验证标准，而不是先编写复杂的提示内容。

以“整理采购申请”为例，验收条件可以包括：必填字段齐全、金额计算一致、供应方信息可追溯、预算检查通过，以及需要审批的事项已进入正确流程。

对于无法自动判断的结果，应明确人工复核规则，避免让模型自行宣布任务成功。

2. 把外部内容视为数据，而不是指令

检索文档、用户上传材料和工具返回内容中，都可能包含误导性文本。系统必须区分“被处理的信息”和“允许改变执行行为的指令”。

尤其在具备工具调用能力时，外部文本不能因为出现在上下文中，就自动获得修改权限、绕过审批或泄露数据的能力。

防护措施应分层实施，包括来源标记、权限隔离、工具参数校验、敏感操作审批及输出检查。仅依靠提示约束，不能保证安全。

3. 对执行行为实施硬预算

智能体可能因信息不足、工具失败或错误反馈反复执行。运行环境应设置明确的资源边界，例如：

• 最大执行步骤数；
• 总运行时间上限；
• 推理与工具调用预算；
• 同类错误连续出现次数；
• 允许访问的数据范围；
• 必须转交人工的风险条件。

这些限制应由程序执行，而不是交给模型自觉遵守。

4. 区分重试、幂等与补偿

并非所有失败都适合直接重试。

读取资料通常可以安全重试；创建订单、发送通知或修改设备状态，则可能产生重复副作用。对于这类操作，应设计幂等机制，避免同一请求被重复执行。

跨系统任务还可能出现部分成功。此时不能简单假设所有操作都支持回滚，而应根据业务语义设计补偿动作，例如撤销未完成的预留、标记异常状态或提交人工处理。

五、物理智能：从“理解场景”到“安全行动”

1. 物理任务比文本任务多了哪些约束

物理智能系统不仅要识别环境，还要在时间、空间和动力学约束下行动。即使语言推理正确，动作也可能因遮挡、定位误差、接触变化或执行延迟而失败。

典型能力链包括：

传感器输入 → 状态估计 → 环境理解 → 任务规划 → 动作生成 → 控制执行 → 反馈校正

其中，高层模型适合解释目标和组织步骤，但涉及稳定性与安全性的底层控制，往往仍需要经过验证的控制器和独立保护机制。

不宜让生成式模型绕过安全控制，直接决定所有执行器的实时动作。

2. 仿真训练的价值与边界

仿真环境能够降低试错成本，重复构造场景，并生成现实中难以大量采集的危险或罕见样本。但仿真并不天然等于真实世界。

材料摩擦、光照、传感器噪声、机械间隙和通信延迟等因素，都可能造成训练环境与部署环境之间的差异。

常见应对方法包括：

• 校准与任务相关的关键物理参数；
• 在合理范围内随机化环境条件；
• 使用真实采集数据验证和修正模型；
• 在受限场地进行分阶段测试；
• 对异常状态设置独立的保护与停止机制。

随机化不能替代物理建模，真实数据也不能保证覆盖所有极端情况。可靠系统需要多种方法共同降低风险。

3. 建立可追溯的数据闭环

有效的训练闭环不只是“采集数据后重新训练”，而应包含：

现场采集 → 数据清洗与标注 → 失败归因 → 场景补充 → 训练更新 → 离线评估 → 受控验证 → 分阶段部署

每次更新都应能够追溯数据版本、模型版本、评估结果和适用边界。否则，当系统行为变化时，团队很难判断问题来自数据分布、训练过程还是运行环境。

对于高风险场景，上线门槛应包含安全指标和独立验证，不能只依据平均任务成功率。

六、如何评估“算力提升”与系统优化

面对大幅性能提升的表述，应先追问比较条件是否一致。

模型规模、数值精度、输入输出长度、批量大小、并发水平、质量要求以及功耗口径，都可能影响结果。只比较某一项理论指标，通常不足以说明完整系统的收益。

实践中建议采用三层评估。

第一层：资源效率。 观察计算单元利用率、内存占用、缓存效果、能耗和单位时间处理量。

第二层：服务质量。 观察端到端延迟、尾部延迟、错误率、请求排队时间和可用性。

第三层：业务结果。 观察任务通过率、人工修正比例、平均交付时间、有效任务成本和风险事件。

三层指标应共同使用。例如，扩大批处理规模可能改善吞吐，却恶化交互延迟；更激进的精度压缩可能减少资源消耗，却降低复杂任务准确率。只有在相同质量和服务约束下，优化结果才具有可比性。

七、企业落地路线：先闭环，再扩展

第一阶段：选择边界清晰的高频任务

优先选择数据可获得、验收标准明确、错误可恢复的流程，例如内部资料整理、工单分类和结构化信息提取。

不宜一开始就让系统执行跨多个业务域、权限广泛且难以撤销的复杂任务。

第二阶段：建立基线与评估集

记录现有人工或传统系统的处理时间、成本和错误类型，建立包含正常情况、模糊输入、异常数据及权限边界的测试集。

评估集应持续维护，并注意避免将测试样本直接用于反复调优，从而高估真实效果。

第三阶段：以辅助模式验证

先让系统生成建议，由人工确认后执行。收集错误案例，区分知识不足、检索失败、规划错误、工具故障和业务规则缺失，避免用同一种优化手段处理所有问题。

第四阶段：按风险逐步开放自动执行

低风险、可撤销、规则明确的任务可以优先自动化；涉及资金、敏感信息、外部承诺或物理动作的任务，应保留更严格的审批与保护机制。

扩展自动化范围的依据，应是可重复的评估结果，而不是少数演示案例。

结语：真正的竞争力来自系统协同

词元提供了观察推理供给的一种计量方式，智能体提供了组织任务执行的新方法，物理智能则把模型能力延伸到了现实行动。但三者都不能脱离工程约束独立成立。

可靠的智能系统，需要模型理解能力、确定性业务逻辑、受控执行环境、数据反馈和安全治理协同工作。对开发者和企业而言，最值得持续优化的不是孤立的生成速度，而是在明确边界内，以可接受的成本，稳定交付可验证结果的能力。