Theo：向智能体请求结果，再构建它需要的工具

提示词工程的热潮曾让人觉得，我们都需要成为精心设计指令的专家。我认为许多工程师的问题恰恰相反：我们过度设计提示词，却错过了重新思考电脑能为我们做什么的机会。我们向智能体提出的要求还不够多。

我自己也仍在学习。和工程师的交流让我发现，许多人还没有意识到，智能体能做的事情可能超出他们分派的狭窄任务。我希望大家走出工程思维的框架，想想自己在工作和日常生活中真正需要什么。

一则旧的 xkcd 漫画展示了用户的要求与工程师对难度的判断之间的差距：检查照片是否在国家公园拍摄看起来很简单，而识别照片中的鸟曾经像一个研究项目。视觉模型改变了后者。今天工程师面临另一个问题：我们太习惯用代码思考，以至于忽略了可以直接请智能体调查的事。

一位朋友希望 T3 Code 增加工具调用耗时分析功能，以便找出慢命令。我最近审计自己的智能体历史时发现，Claude 的 ripgrep 调用经常失败，因为面向 Bash 的命令在我的 Zsh 环境中不能正常运行。朋友想要的信息，其实已经可以由智能体获取。

我打开一个新线程，请它分析这台机器上的工具调用。生成的报告显示，其中一次主目录搜索耗时 41.7 分钟，另一次约 9 分钟；报告建议改为搜索仓库或已知目录。无需先为这个具体问题开发专门功能，我就获得了有用的信息。

我们习惯于认为，工具必须先有某个功能，才能从中取得信息。但如果相关数据已经可以访问，智能体往往能回答临时提出的问题。这并不意味着所有功能都应该消失，而是说有些信息需求不必先开发专用界面。

我曾为 T3 Code 中的所有活动任务设计一个仪表盘：显示状态、给出建议、提供重命名线程的按钮，以及处理 PR 的方式。随着控件越加越多，我意识到还有另一种选择：让一个连接各个环境的元线程按需提供我想看的视图或分析。

我还请智能体把线程的上下文窗口可视化。之前一次类似分析发现，我的代理配置在每个请求中额外加入了约 7 万个 token。生成这些报告需要时间，但如果任务可以在后台运行，我就不必停止其他工作等待。

关键的变化是，开始请求那些有用却不足以值得开发成永久功能的一次性结果。我曾制作可视化来理解一个具体 bug，也曾合并来自不同服务的音乐收听历史。这些都是我可能原本不会做的事，并不一定需要维护成产品。

有人希望能够选择受委派智能体使用的模型。在我的配置中，模型本来就会选择委派对象，因此我可以在提示词里说明要求。我演示了如何让一个智能体启动两个 Opus 委派任务来探索性能优化，再用另一个模型打开独立的实现线程。

在这个例子里，请求本身就控制了委派模型，不需要新的下拉菜单。如果发现自己不断重复同一条指令，我才会考虑更新技能或智能体指令文件。生成的上下文窗口报告也可以通过继续提问来调整；如果足够有用，再把它变成可复用技能。

这种思路也改变了我构建产品的方式。一位 Windows 用户遇到了严重的 T3 Code 问题，我发现自己在为他编写提示词，让他在自己的机器上交给智能体执行。这启发了 T3 triage：一个即使桌面应用无法打开也能使用的命令行排障流程。

它没有用大量自定义代码构建一个逐项提问的复杂应用，而是收集基本机器信息，让用户选择智能体运行环境，再把排障手册交给它。智能体扮演支持工程师：理解问题、帮助用户解除阻碍，并在适当时准备一份有用的问题报告。

手册首先要求用户用自己的话描述发生了什么；如果有截图就提供，描述含糊时继续追问。好的复现步骤尤其有价值。随后它读取机器信息、检查是否有更新版手册，并可以查看开源代码。

智能体调查问题，并检查上游是否已有修复。如果确实需要提交 issue，它应先清理秘密和其他敏感数据，并优先补充到已有 issue，而不是创建重复报告。我原本预计这个功能需要几千行代码；我介绍的版本只需要一个小命令和一份 Markdown 手册。

我曾花时间尝试让自定义排障界面处理粘贴的图片，后来才意识到所选智能体可以直接请用户提供截图。动态故障排查有许多我无法预见的分支。如果我事先知道所有故障，就会直接修复它们，而不必构建排障工具。

那么还有什么需要工程实现？其中一个答案是让智能体获得更好的证据。我曾遇到 T3 Code 界面闪烁，怀疑日志不足以事后调查。我于是询问智能体是否能获得历史渲染数据，以及我们可以暴露哪些信息，让未来的调试更有效。

我还请一个桌面智能体描述它能使用的电脑操作能力。它列出了发现和操作应用、读取界面、使用截图与辅助功能信息、操作鼠标和键盘，以及验证结果等能力。我把这份描述作为在 T3 Code 中开发类似能力的输入。

你可以问智能体为什么没有给 PR 附截图、需要什么工具、调查为什么停滞，或者它能否查看另一个线程。你可以询问自己的提示词、工具、程序和系统，而不只是要求修改代码。答案仍然取决于智能体实际拥有的数据和访问权限。

我甚至曾用智能体帮助我从医疗门户收集文件交给医生。我本可以为此编写程序，但对我来说，直接提出一次性任务更有用。重点不是提示词能取代所有程序，而是它让一些原本不会值得我开发专用工具的工作变得可行。

当我发现哪些请求有用之后，就可以把工程精力集中在它们需要的基础能力上：工作流、工具、管道、数据访问和系统之间的连接。当智能体能取得完成请求所需的信息时，提示和构建就能互相促进。

一个个人例子是把多个邮箱连接到 ChatGPT。手受伤后，我更难处理邮件，于是尝试向智能体询问邮件，发现自己查看收件箱的次数减少了。这是我自己账号和工作流中的经验，并不保证所有配置都会有相同效果。

我可以请智能体寻找某类账单，然后调查相关控制台中的费用上涨。在我的配置中，我通过 MCP 连接了 T3 Code，因此工作可以在其他智能体线程中继续。关键是把数据和工具连接起来：提示词能够跨系统工作，而不必止步于收件箱。

这种变化有时让我觉得自己不再像工程师，因为我不再关注每个框架或每一行代码。后来我意识到，为智能体建立可靠的运行系统，会带来新的工程问题。构建排障流程、通过 MCP 暴露应用，或提供有用的数据，都是工程工作。

我一直在尝试 Rust 应用和成本更低的智能体计算基础设施。过去成本太高、或者对足够多的人没有用处的问题，如今可能变得值得解决，因为智能体让构建更容易，也让更多人能够使用结果。这正是我现在感到兴奋的地方。

我经常看到 T3 Code 的功能请求，其中一些可以先向智能体提问，而不是立即增加专用按钮。但这种方式仍需要良好的基础能力。例如，智能体现在可以生成 HTML 可视化；如果支持内联可视化，用户就能直接在产品内看到动态生成的视图。

对于觉得 AI 带走了自己热爱工作的部分的工程师，我理解这种不适。我自己在熟悉的工作发生变化时，也经历过信心下降。我认为，当你不再只盯着智能体写出的代码，而开始关注它周围需要构建的系统时，可能会看到新的机会。

过去我花更多时间组装面向用户的方案；现在我正在探索操作系统、编译器和连接层，因为这些问题对我的工作更重要，也更有可能解决。我不会检查每一条 SQL 查询，但可能会深入思考数据库和服务器之间的连接。

这是我的个人经历，并不保证每个人都会有同样的转变。我想邀请大家提出更广泛的问题，看看智能体缺少什么，再构建让这些请求成为可能的系统。仍有很多工程工作可以做，也有很多创造新东西的空间。