Context Is All You Need?
信任 AI
我此前在 Microsoft 实习做 agent 时，我们的工作几乎都集中在 SWE-Bench 类的任务上。然而这类任务的几乎所有工作都在单个仓库内执行，且开发环境简单，能够调用 terminal 工具的极简 agent 就能够完成，分数很大程度上取决于模型自身的能力。
我们当时的研究工作表明，在模型能力足够强时，agent 框架的重要性会大大降低，因此我们应该选择相信模型的能力，只为模型提供最简的 agent scalfold。我们相信，模型能力足够时，其完全可以通过工具的最简描述，自己组织上下文以解决问题。
在 SWE-Bench 的场景下，agent 通过终端工具运行 grep、find 等命令就可以读取文件，找到与需求相关的代码片段。这就是上下文组织的一个简单例子。在此基础上，我们不难提出：agent 开发最重要的工作就是赋予 agent 获取上下文的能力。
保障 AI
然而在实际业务场景中，可能会存在大量的内部平台。举个例子，我们的模型训练可能需要在线上 IDE 平台 A-IDE 改动模型的代码、指定框架版本，而后提交训练任务，然后内部的训练平台 A 会给我们的任务调度并分配资源。
但是由于平台的工作机制，我们在 A-IDE 上无法改动框架的代码。如果模型的新设计要求我们添加或改动框架版本，我们的工作流程应该是：
- 在开发环境改动框架代码并本地测试
- 将框架代码推到包管理平台进行标准环境下的编译与发布
- 在 A-IDE 上更改框架的版本
这时，基础的 AI Agent 就无法解决这个问题。
这就引出了本文标题的问题：如果你在开发环境中部署了一个 Agent 帮你开发框架，它是无法直接拿到 A 及 A-IDE 平台上的信息的。以 Agent 的工作方式来说，我们向 Agent 描述我们的需求，它会去各个代码仓库中探索自己必要的信息，如函数签名、接口契约等。
这些信息让人类来协调组织无疑是低效的。因为这些框架的代码基本都是AI写的人类根本看不懂 于是有了针对这些平台的工具。
开发团队给出的解决方案是提供 cli 工具和对应的 skill。cli 工具可以通过传递参数获取训练任务的状态、日志、代码等，也可以提交更改后的代码、在平台上提新的任务等。只要由用户先使用 cli 工具进行身份认证，cli 工具就可以使用用户的权限与平台交互。
这种方案有一种简洁的优雅：cli 本身就是一个可执行命令，agent 不需要引入任何新的 tool call，直接通过终端工具就能调用。agent 框架里不用加一行代码。而 skill 文件做的事情也很纯粹——它只负责向模型描述这个命令有哪些用法、参数怎么填、什么时候该用它。本质上是把”怎么调”交给 skill 描述，“调什么”交给 cli 实现，两者都围绕终端这个 agent 已经具备的能力展开，没有引入任何新概念。这比在 agent 框架里为每个平台定制 tool call 要轻量得多，也更通用。
Context Is Not All You Need
什么精神分裂？
前两个部分其实在这篇博客发表前几天就已经写完了。在使用以上方法论完成了最初的需求后，我需要对我们的框架做进一步的更改。这让我有了一些新的感想：
Context is all your agent needs. Thoughts is all you need.
在完成了最基本的功能后，我需要对框架做进一步的更改，使其能稳定运行。如先前提到的，我们的框架可读性极差，这让我先走上了 AI 替代大脑的道路：我试图让 AI 在理解所有上下文后自己制定方案、自己实现。然而 AI 给出的方案完全不符合预期。
于是我又开始尝试动用我僵化的脑细胞去理解代码。我再次意识到这坨代码无法理解，但在多次对话中，我逐渐理解了整体的架构，从框架先前已实现的功能中推断出了较为可行的扩展方式。整理完需求后交由 AI 实现，终于能够得到符合预期的结果。
受限于保密要求，我无法展示具体的任务和需求，这让这篇博文显得非常得枯燥乏味。说实话，我原本也觉得这都是些谁都知道的道理，但确实得在实践中才能摸索出一些具体的经验。也许在未来公司允许时，我会结合具体的需求对这篇文章做一些补充。
最后，不要放弃思考。也许在 AI 带来的技术平权面前，思考才是人类的价值所在。