多智能体系统最容易被低估的部分，不是角色拆分，而是状态管理。一个业务任务往往要经过意图识别、规则核验、人工审批、系统写回和结果通知；如果编排层只保存“下一步调用谁”，却没有记录任务当前处于何种状态、依据哪些数据作出判断，系统就无法稳定处理暂停、重试、回滚和人工接管。
状态不等于对话上下文
生产级编排至少需要区分三类状态。第一类是业务状态，例如采购申请是否完成预算核验、合同是否已审批、订单是否已经写回ERP；第二类是执行状态，例如某个智能体是否已接收任务、工具调用是否成功、接口是否超时；第三类是治理状态，包括当前使用的身份、审批人、数据来源、模型建议和人工修改记录。三者混在一起，异常定位和责任追踪都会变得困难。
状态还应具备明确的生命周期。任务不能仅用“进行中”或“已完成”概括，而应支持等待人工确认、执行失败、可重试、已转交人工和已终止等中间状态。每次状态变化都应留下可追溯记录，并说明触发原因。这样，编排智能体才能回答“当前流程停在哪里”“下一步由谁负责”“失败后是否允许继续”，而不是重新猜测上下文。
可靠编排的三个原则
首先，状态更新必须与业务动作保持一致。执行智能体调用系统后，不能仅依据“请求已发出”就标记成功，还要回查目标系统的实际结果，避免出现流程显示完成、业务数据却未写入的情况。
其次，重复执行必须可控。网络超时或响应丢失时，编排层可能无法判断动作是否已经生效。涉及创建订单、提交付款申请等操作，应依靠幂等设计、结果回查和人工确认，避免盲目重试造成重复业务。
最后，状态应支持人工接管。高风险动作不宜由智能体直接闭环，而应记录待确认事项、所依据的数据和建议结果。人工处理后，系统继续沿用同一任务状态推进，并保留修改痕迹。
多智能体协同的核心，不是让更多智能体同时工作，而是让每个动作都能被准确定位、验证和恢复。状态管理实际上连接了任务规划、权限控制、系统执行与审计责任；没有它，多智能体只是多个会话的拼接，很难成为可治理的生产流程。