我用一个 Codex skill 替换了一个相当复杂的 Reddit 研究智能体。我开始觉得很多“智能体”其实就应该做成 skill。

我最近看了不少研究型智能体（research-agent）项目，其中大多数其实都可以直接用 codex 之类的工具替代。在今天这个时代，像 Codex 这样能力足够的 harness 已经具备了推理、联网、工具执行、文件系统访问和交互式对话能力。但人们总说：“把代码给我看看。”于是我就尝试拿一个相当复杂的 Reddit 客户研究智能体的工作流，把这个用例改造成一个 Codex skill 来实现。它会研究 Reddit 上的客户痛点、验证相关社区、收集证据、对问题进行聚类、分析商业信号并生成结构化产物。在正式研究开始前还会有人工审批检查点。 对我来说，这里（唯一）有趣的地方在于：我不需要构建哪些东西——没有单独的智能体循环/运行时，没有单独的 LLM 客户端，没有嵌套智能体，没有自定义浏览/搜索层，没有专用 UI，也没有仅仅为了编排研究而单独搞一套框架。 Skill 定义了研究方法和流程，Codex 提供了 harness。我只有在需要确定性行为的地方才保留了一些小型 Python 辅助函数：验证、评分、规范化 URL、去重和产物生成。 所以架构基本上是这样的： Codex harness → SKILL.md 工作流 → 需要时使用确定性辅助函数 而不是： 自定义智能体 → 模型集成 → 工具 → 搜索 → 状态 → UI → 编排 → 报告生成 还有一个有用的副作用：工作流并不会在“研究智能体”返回报告后就结束。因为它运行在 Codex 内部，我可以在同一个对话里继续追问，让它进一步调查某个发现、质疑某个假设、修改分析，或者基于结果开始构建一些东西。 另外，Codex 现在也有了 $skill-creator，所以如果你已经有一个可用的工作流，你可以让它把当前工作流/对话变成一个可复用的 skill，而不必手动从零创建一切。（我在这里就是这么做的） 我越来越觉得，在构建专门的研究智能体之前，应该先问这个默认问题：这个用例真的需要一个新的智能体运行时吗？还是它只需要一个运行在现有 harness 内部的领域专用 skill？ 显然，有些情况下自定义智能体/运行时是有必要的——尤其是当部署模型、独立执行、自定义集成、控制边界或产品 UX 本身就是需求时。但对于大多数“研究智能体”项目，我并不认为它们需要这些。