状态机、控制论和环境治理：重构 Agent 系统

最近越来越清楚地感觉到，Agent 系统真正的瓶颈不只是模型能力，也不只是某一个执行器是否足够主动，而是整个运行环境有没有被设计成一个可理解、可反馈、可持续迭代的系统。

先承认执行质量并不稳定

有些管家型 Agent 在执行任务时会很快停下来，主动性不足，部署推进也因此变慢。遇到这类情况，不能把全部工作都寄托在单一的管家上；需要让更适合长程执行的 LLM 参与具体工作，同时保留原有的安全治理。

但安全治理本身也可能走向另一个极端：过度保护。一个系统如果对每个动作都设置过多阻碍，Agent 虽然更安全，却很难把事情做完。因此，治理不能只是不断增加限制，也应该定期检查哪些保护已经变成了不必要的摩擦，并在测试和审计后清理它们。

比较现实的方式，是一边治理、一边开发。功能继续推进，测试和审计持续补上；当某个保护规则阻碍了正常执行，就回到系统层面判断它是否合理，而不是临时绕过所有边界。

通过飞书 CLI 派发消息、推进工作流，是一种很有价值的模式。手机端不必亲自完成每个动作，只需要和一个入口聊天，由它派发任务、跟踪状态，再把结果反馈回来。

但是当任务线路变多，人的脑力仍然会成为瓶颈。问题不再只是 Agent 能不能执行，而是人能不能快速理解各条线现在处于什么状态，并给出下一步反馈。如果系统把大量细节原样推给人，信息越多，反而越难推进。

因此，任务状态必须被翻译成人类容易理解的分类：当前在哪个阶段、下一步能做什么、依赖是什么、是否阻塞。只有状态信息足够清楚，人才能在多条工作流之间做出有效决策。

我越来越倾向于把 Agent 工作流理解成状态机。状态机回答的是：现在处于哪一步？在这个状态下允许执行什么行为？什么条件会触发下一次流转？

从这个角度看，Agent 的执行流程和传统程序并没有本质断裂。过去的程序是固定的 if/else 和顺序流转；Agent 则在这些节点中加入了判断和一定的随机性。它仍然需要沿着状态前进，只是节点内部不再完全由固定代码决定。

状态机的价值，是把这种不确定性放进明确的边界里。系统知道当前状态，也知道从当前状态可以走向哪里；Agent 可以在节点中寻找解法，但不能随意改变整个流程的语义。

Agent 执行任务时，有些原本需要逐步展开的序列，经过反复运行后可以被压缩成更高层次的一步。发现规律、提炼规则、固化环境，本质上都是把多个重复步骤压缩成一个可复用的动作。

智能不仅是搜索更大的答案空间，也包括把已经理解的过程沉淀下来。压缩得越多，下一次执行就越不需要重新消耗上下文，系统也就能把注意力放到更高层的问题上。

这也是为什么不能只盯着单次任务的结果。每次 Agent 处理不好的内容，都应该被记录下来，反馈回环境，转化成更好的模块、规则或检查机制。下一次遇到类似问题时，系统就不必从头试错。

控制论和系统论提供了另一个重要视角：系统不是执行一次就结束，而是通过反馈不断修正自己。Agent 做出动作，环境返回结果；结果暴露出的偏差，再进入下一轮治理、模块化和流程设计。

因此，真正值得建设的不是一个只会接受命令的 Agent，而是一个能形成反馈闭环的环境。它能够知道哪里出错，知道哪些结果不可接受，也知道什么时候应该停止并交回人工。

代码架构中的模块化、工作流中的节点拆解、状态机中的流转条件，以及控制论中的反馈回路，实际上指向同一个目标：把复杂系统拆成可观察、可修正的部分。

理想的运行环境不是放任 Agent 随意行动，也不是用无数人工确认把它锁死，而是把边界、工具、反馈和停止条件配置清楚。这样，即使 Agent 的智力足够强大，也不能越过环境的约束，只能在允许的范围内寻找更好的解法。

当环境能够自洽运行，失败能够反馈，规则能够迭代，Agent 才有可能真正完成自我迭代。人的角色也会随之变化：从不断盯着每一步，转向设计状态、环境和反馈机制。

现在还不一定已经产出了足够显性的成果，这会让人焦虑。但持续推进并不等于盲目等待。更重要的是让每一次尝试都沉淀为系统的一部分，最终把耐心转化为一个可运行、可验证、能够自己闭环的实际系统。