这段时间，大家对 AI agent 的期待开始从幻想全能走向建设系统，稳稳干活这件事越来越被关注。
这其实是个合理回调。幻想太多实践太少带来的就是泡沫狂欢。预期回落之后，才开始看到一些工程视角更完整、运行机制更清晰的架构设计跑出来。
先抛个共识出来：语言模型能调用工具 ≠ 能完成任务。
大家的目标很一致：agent 想完成复杂任务，靠 prompt 编程是走不远的。LLM 要在什么边界内学会控制组合，有点类似于 agent+workflow 逻辑之上的进一步验证。
Manus 这个也非常典型，继上一次的上下文工程六大法则之后，Manus 又往前迈了一步，他们没再幻想让 LLM 一口气接所有工具，而是老老实实把拆成模块化的结构。
我个人非常认同这个方向，甚至可以说它定义了下一阶段 AgentOps 的底层参考结构。
在我看来，这种设计方向至少明确了一件事：
agent 在成为能干一切的通才之前，先稳扎稳打做一个可以调度不同专业能力的系统协调器。
特别是 agent as tool 的机制，用子智能体模拟模块化外包，智能体之间可以互为工具，封装调用并且相互之间不污染上下文。这就是我之前说的上下文线程隔离和调度系统组件化这套逻辑，开始慢慢有了样子。
这套逻辑可能是拆对工具、隔离好上下文、控制好调用深度、规划好执行流程，然后让智能体像微服务一样协作，而不是共享一个 prompt 狂堆 token。
这次从自然语言调用工具到结构化调度能力的范式转移，Manus 提供的思路，值得每个人深度研究。
接下来的方向我只想说一句：
下一波 Agent 竞争，一定不会是 prompt 层的比拼，这是半年前的叙事逻辑。一步是 AgentOps + 系统架构层的总成效能的比拼。
