如何让AI智能体处理复杂工程任务？Together AI总结了六个经验

各种AI编程助手越来越火，像Claude Code、Cursor这些工具确实能帮程序员写代码、调试问题。

但是，让AI去完整地处理那些复杂的、需要跑几天甚至几周的工程任务，这还是个相对新鲜的领域。

Together AI这家公司就遇到了这个问题。他们在优化大模型推理速度时，发现有很多繁琐的工作：配置环境、启动任务、监控长时间运行的进程、收集结果等等。

这些工作流程，往往因为系统设计的复杂性和规模而难以自动化，而且可能需要数天甚至数周才能完成，需要持续的人工监督来处理频繁出现的故障和边缘情况。

为了解决这个问题，Together AI开发了一套智能体系统，显著减少了人工干预，同时保持了一致性和可靠性。

通过大量实验，Together AI总结出了两套核心模式：基础设施模式和行为模式。

现在工程师们可以专注于监督和控制整体进程，让智能体来处理那些"无聊"和重复性的工作。

选择自动化任务的三个标准

不是所有任务都适合让智能体来处理。经过实践，他们发现适合自动化的任务需要满足三个条件：

可验证性：要有明确的成功或失败条件。

明确定义：步骤和边界要清晰明确。

工具支持：要有现有工具支持，或者能够合理集成相关工具。

此外，这些任务通常对人类来说是重复性的，在不同实例间只需要相对较小的调整。比如基础设施配置、任务监控和机器学习管道中的超参数调优就很符合这个描述。

基础架构方面的三个模式

1. 好工具

AI智能体本身已经很聪明了，能看懂文档、执行命令、对输出结果做反应。

关键是要给它们好用的工具。这里的"工具"就是智能体与环境交互的方式，比如读文件的cat命令就是一个工具。

好的工具应该设计得稳定、信息丰富，错误信息要清晰，日志要完整。当智能体遇到问题时，它能通过这些工具找到解决办法。

举个例子，他们的训练脚本需要用到一个特殊目录，这个目录在训练节点上有，但在Docker环境里没有。一开始他们没考虑到这点，智能体遇到这个问题后，能够自己想办法指定新的目录来解决。

2. 好文档

好文档和好结果几乎是完美相关的！

有了全面、结构清晰的文档，智能体就能持续稳定地执行正确操作。

他们的文档不只包含正常流程（就是手工操作的步骤），还包含可能的失败情况和边界情况。

更重要的是，文档里还解释了每一步的原理，不只是机械的操作步骤。这样智能体遇到新情况时，能做出更好的判断。

3. 高安全

让智能体访问重要基础设施，安全问题不能忽视。人类操作员有判断力，知道哪些操作有风险，但智能体往往会按字面意思执行指令，缺乏直觉的安全机制。

他们的解决方案是大量使用开发环境，这些环境和生产环境很相似，但权限受限。智能体在Docker容器这样的沙盒里自由实验，用专门的API密钥（权限很细），不会影响生产系统。

行为模式方面的三个模式

4. 管理并行会话

传统的智能体通常处理短期任务，完成后就退出。复杂的自动化需要智能体能启动进程、监控几小时甚至几天、在中断后还能保持控制。

一开始，他们的智能体会启动模型训练这样的长时间任务，然后要么在等待时无响应，要么完全失去对关键进程的控制。

他们用tmux（一个终端复用器）优雅地解决了这个问题。tmux会话在智能体重启后依然存在，遇到意外故障时能恢复。智能体遇到错误需要重启时，可以重新连接到现有会话，继续监控而不丢失工作。

而且人类也能随时登录检查智能体的工作状态。

5. 管理等待时间

最反直觉的一个经验是教智能体什么时不要行动。

早期实现中，智能体会过度监控：持续轮询训练进度，用重复的状态检查填满上下文窗口，在不必要的活动上浪费计算资源。

他们采用了一个简单的模式：让智能体估算完成时间，然后就sleep（休眠），过一段时间再醒来检查任务状态。

虽然也可以用其他方式实现，但sleep是最简单的。

6. 进度监控

一开始，他们的指令只描述智能体要做什么，没有额外的上下文。所以如果智能体运行某个命令，它可能不知道这是一个需要10分钟才能启动的服务器。

早期版本的流水线会执行命令，如果没有明显错误就认为成功了。

这导致一些微妙的故障几分钟后才暴露出来。比如，智能体会启动推理服务器，然后立即开始发送HTTP请求，而不等推理引擎完全加载模型。

有效的进度监控需要改进文档，告诉智能体命令有一些上下文，可能需要更多时间才能完成。如果明确告诉智能体某个操作是为32B模型启动推理引擎，智能体通常足够聪明，知道可能需要等待。

实战案例：自动化投机训练流水线

投机解码（Speculative Decoding）是高效大模型推理的核心技术之一。

简单说，就是用小模型（草稿模型）来猜大模型会说什么，大模型只需要验证和纠正小模型，而不用从头生成所有token。这个过程可以并行处理多个token，所以速度快很多，能让大模型推理速度提升2-3倍。

Together AI为各种模型训练投机器的流程特别适合自动化。

整个训练流水线包含多个相互关联的步骤：环境设置、从大目标模型生成数据、训练小的草稿模型、评估效果。每个步骤都涉及复杂的命令序列、错误处理和时机考虑。

人工监控既枯燥又容易出错，一个细微的配置错误就可能让几小时甚至几天的宝贵计算时间白费。

他们的系统架构包括：

1. 容器化环境：为特定任务优化的Docker容器，预配置了依赖项和工具
2. 智能体编排：测试了OpenHands和Claude Code，都能跟随复杂的指令链

智能体通过复杂的工作流程操作：解析实验需求生成执行计划 → 选择适当环境 → 使用tmux会话启动和监控推理引擎实例 → 运行训练工作流程并智能管理检查点 → 收集和整理所有实验产出。

最终结果很不错：在一个32B推理模型上，他们观察到1.22x到1.37x的每秒token速度提升，同时最小化了人工干预，把配置和调试的重复工作交给了智能体。

未来的挑战和机会

虽然系统显著提高了开发效率，但还有一些持续的挑战：

上下文管理仍然是问题。复杂实验产生大量日志，超出当前上下文窗口限制，需要探索更好的总结和状态管理技术。

新型故障模式很难处理。智能体能很好地处理文档化的错误，但面对全新的边界情况时会困难，需要持续更新工作流程文档。

资源优化还在发展中。当前智能体做出保守的资源分配决策，正在努力实现更自适应的实时资源管理。

总的来说，用大模型智能体自动化复杂工程任务确实可行，关键是要有好的架构设计、完善的文档、安全的执行环境，以及合理的行为模式。

这个领域还有很大发展空间，未来可能扩展到DevOps、科学研究、业务流程自动化等更多领域。