模块化框架适合哪些业务场景?

模块化框架不是“系统越复杂越高级”的装饰品。对只做固定问答、整理短文本的业务来说，把能力拆成很多层，反而像为了买杯咖啡先开一场项目会，成本未必划算。它真正适合的，是那些任务会变、资源会增、出错代价也不低的业务。

多能力协同的业务

一个智能体既要读取文件，又要查询内部数据，还要把结果交给不同流程处理时，就不宜把所有事塞进一个“大总管”里。否则结果不对，大家很难判断是模型理解错了、数据有问题、工具没执行，还是流程接错了。

模块化的好处在于把职责拆开：模型负责理解和判断，工具负责执行确定动作，文件与数据单独管理访问范围，调度层决定哪些步骤自动推进、哪些必须停下来等人确认。业务以后增加能力或替换服务时，改动也不会牵一发动全身。

规则经常变化的业务

有些业务的难点不在一次性上线，而在规则总会调整。比如同一类任务，面对不同场景，需要换不同的工具权限、审批条件或处理路径。模块化框架更像一排可替换的抽屉：某个环节要换，不必把整张柜子砸了重做。

不过，“能替换”不等于随便接。组件一多，接口约定、输入输出、异常状态和维护责任都要说清楚。要是工具只写着“可以查数据”，却没说明查什么、谁能查、失败后怎样处理，模块化很快就会变成“模块化甩锅”。

有权限与误操作风险的业务

只读资料、生成建议、修改内容、发送通知、触发外部操作，显然不是一个风险等级。只要业务涉及敏感数据、外部系统变更，或可能造成不可逆后果，就适合用模块化把权限卡在具体任务和具体工具上，而不是把一整套权限交给智能体。

较稳妥的设计是：低风险查询在限定范围内执行；修改类动作增加条件；高风险操作设置人工确认。真正执行前还要再次检查目标资源和当前任务是否匹配，不能因为前面“看起来合理”，就一路放行。

说到底，模块化框架最适合持续迭代、多人维护、资源来源多、失败需要追溯的业务。它不保证系统永远不出错，但能让错误有边界：知道错在哪、该不该重试、什么时候该停下来交给人处理。这比让智能体显得无所不能，更接近业务真正需要的可靠。