我在加密货币领域进行智能体工程的工作流程

  • mteam88
  • 发布于 5小时前
  • 阅读 30

本文介绍了在加密货币开发中使用 Agentic Engineering(智能体工程)的方法,强调了利用AI工具提高开发效率和代码质量的重要性。文章分享了作者在实际项目中的经验和技巧,包括心态调整、工作流程优化以及安全注意事项,旨在帮助开发者更好地将AI融入到加密货币开发中。

I. 引言

类代理(Agentic)工程开发需要与传统编程不同的思维模式和工作流程。在加密领域构建任何东西都需要类似的转变。因此,对于普通开发者来说,加密领域的类代理工程开发在复杂性上要高出两个层次。

- “类代理(agentic)” 是因为新的默认情况是,你 99% 的时间不是直接编写代码,而是编排代理来完成,你充当监督者的角色。

- “工程开发(engineering)” 强调其中蕴含着艺术、科学和专业知识。它是一种你可以学习和变得更好的东西,具有不同深度的内涵。

karpathy

对此有两种极端的反应:一些加密领域的开发者选择几乎不使用 AI 来完成他们的工作(通常会合理地引用安全问题)。随着围绕 Claude Code 和 Codex 的炒作,这个群体正变得越来越小。另一方面,一些开发者选择完全采用混乱模式(slop mode)和凭感觉(vibe)完成一切。这在加密领域目前根本行不通。像对待业余项目一样使用这些工具是低效的。

在本文中,我将概述如何通过我过去 2-3 个月来在加密领域开发生产和业余产品时使用的一些工具和技巧来提高你的生产力和输出质量。

本指南将更侧重于一般的类代理工程开发,因为这与加密领域有很多重叠,而且我希望我的大多数读者已经熟悉基本的加密开发工作流程。

我对于类代理工程开发的一般理念和方法是:尽可能地将自己从反馈循环中移除。与其截取前端的屏幕截图并要求 claude 修复视觉错误,不如告诉 claude 自己打开浏览器并截取所有内容以确保它正常工作。话虽如此,与新手或非技术人员相比,熟练的工程师每次花费的 token 将取得更大的进展。在将自己从反馈循环中移除但仍然指导进展之间存在微妙的平衡。

类代理工程开发(Agentic Engineering) 意味着将 AI 集成到你现有的开发工作流程中。当目标是高质量的软件时,熟练的工程师是不可替代的。它是关于通过深思熟虑的协作来增强我们所能完成的事情。

Zed

II. 心态

对于 AI 工具的新手开发者来说,最大的错误是心态不好。在接触任何工具之前,你必须以某种特定的心态来对待类代理工程开发。

首先,你必须说服自己,在正确的工具和背景下,AI 可以做任何事情。对 agent 的能力持悲观态度几乎毫无帮助。现在,这并不意味着你应该用 AI 来做所有事情 - 仅仅因为 claude 可以 做某事并不意味着它 应该 这样做。这种心态的转变将帮助你专注于将 AI 用作协作者而不是工具。

其次,你必须将 context(提示、代码、技能、MCP、工具等,它们是 LLM 的输入)视为宝贵的货币。大量的基准测试证据表明,LLM 的输出质量 context 长度和 context 质量的 高度影响。许多开发者 通过轶事报告 感到随着 context 长度的增加,出现了“ context 腐烂(context rot)”。膨胀的 MCP 和冗长的线程是导致 context 爆炸的主要原因,应该避免这两者(更多内容将在下一节中介绍)。此外,为你的 agent 构建和加载信息(例如将 Notion 文档导出为 markdown 而不是使用 Notion MCP)可能有助于提高输出质量。Agent 会比工具响应更关注你的提示。当然,应该避免压缩。

第三,你应该尽可能地记录你的意图。代码注释已经过时了,但是 markdown 文档很有价值。编码 agent 乐于说服自己你希望系统以某种方式运行,即使你在之前的会话中提示他们相反。AGENTS.md 是一种方法,但几乎任何有意识的方法(包括代码注释、markdown 计划、专用文档、编写良好的 README)都可以正常工作。

最后(也是最重要的一点),在提示之前先思考。 你的目标是让你的 agent 尽可能长时间地(高效地)运行。始终考虑如何让 agent 获取他们自己对于新功能或错误修复的反馈,而不是问你。TDD 又流行起来了。简短的提示可能有效,但花额外的几分钟来确保 agent 可以在没有你帮助的情况下运行额外的半小时几乎总是最好的。这不仅会提高你的生产力和输出质量,而且管理起来也会感觉轻松得多。

III. 工作流程和工具

这些将在未来几个月内发生显著变化。专注于类代理编码的本质,而不是具体的工具。

以下是我使用的工具:

  • Takopi - 用于编码 agent 的 Telegram 界面(比你想象的更有用)
  • Cursor - 用于导航文件、快速 Composer 查询和编辑 .env 文件。我很少使用 Cursor Tab。
  • Codex CLI - 用于驱动 agent 的主要界面(我只使用 claude 进行前端设计)
  • Codex App - 我使用它的工作区管理功能,并且用它进行更长的提示是一种乐趣。不幸的是,它是一个资源消耗大户,因此不是我首选的移动编码工具。
  • sir - 我创建的一个小型 CLI 工具,用于管理并行编码 agent 的 git worktree 并智能地合并冲突的更改
  • 技能:我拥有用于加密工具的多个自定义技能,例如 cast 和 foundry。我不会在这里分享这些,因为它们非常适合我所从事的项目类型。我鼓励你制作自己的技能(Codex 具有 Skill Creator 技能,适用于此)。
  • MCP:Linear、Etherscan 和 context7。仅此而已。

这是我的工作流程:

  1. Git init/clone 并在 repo 根目录中打开 Cursor

  1. 使用 sirCodex App 创建新的 worktree。

我使用以下命令来设置 worktree(由 Codex App 和我的工具自动运行):

claude -p "You need to setup this new worktree. Copy any and all files you may need from the root checkout to this one, for example .env and build directories. We are on macos, so you may use the -c flag on cp for Copy-on-Write if desired. Don't symlink, as I don't want changes from this worktree to affect the source." --dangerously-skip-permissions
claude -p "你需要设置这个新的 worktree。将你可能需要的任何和所有文件从根检出复制到这个 worktree,例如 .env 和构建目录。我们使用的是 macos,因此你可以在 cp 上使用 -c 标志进行写时复制(Copy-on-Write,COW)。不要使用符号链接,因为我不希望来自此 worktree 的更改影响源。" --dangerously-skip-permissions
  1. 使用 codex 进行迭代提示和审查以取得进展。如果我要长时间不在办公桌前,偶尔会使用 takopi 恢复。我会在这个过程中或在第 4 步中进行 git 提交。

  1. 使用 sir settle 或 Codex App 的应用工具合并回主分支(或另一个分支以进行 PR,如果我与其他人一起工作)。我几乎不再使用手动 git 命令。

对你而言,最高的杠杆工作流程可能与我的不同,因此以下是我在设计此工作流程时想到的一些事情:

  • 并行编码 agent:我通常一次只从事一个项目,并且 Codex 非常(一丝不苟地)慢。这意味着如果没有并行编码 agent,我会在开发时 >50% 的时间内无所事事。Twitter 太容易让人分心了,所以我开发时完全避免它。
  • Git worktree:许多最好的类代理工程师(包括 @steipete)在 同一文件夹 中使用多个 agent。其他人使用多个检出进行隔离。我发现 worktree 可以通过我的 sir 工具进行管理,并且在同一文件夹中工作的多个 agent 通常会导致难以解决的冲突(通常需要中断多个不同的线程)。
  • gpt-5.3-codex vs. opus-4.6:我一直更喜欢 codex 模型而不是 opus,因为它们感觉更有耐心,并且更愿意在进行更改之前研究存储库。这是防止大型和复杂的项目陷入混乱的唯一方法。
  • Codex cli > opencode:我从未找到理由喜欢 opencode 而不是第一方 CLI 来进行我的主要工作,并且我不喜欢它们的 tui 界面。我安装了它,偶尔会使用它来测试开源模型。我喜欢 pi 并且没有尝试过 Amp。
  • 计划:我不再为 CLI agent 使用计划或计划模式。对于复杂的任务或新项目,我将从 ChatGPT 的 Deep Research 或 5.2 Pro(也请参阅 steipete 的 oracle)开始,并为编码 agent 生成一个 markdown 计划。我发现很难让编码 agent 反驳不好的想法,但 5.2 Pro 会在你询问时这样做。
  • jj?tmux?Conductor? 我发现保持我的工作流程简单明了是有帮助的。类代理工程开发已经更加费神,使用高认知负荷的工具根本不值得。
  • 斜杠命令:我发现大多数人使用斜杠命令或拥有额外的技能,用于基本上只是他们重复多次的提示(例如创建 pull request、提交等)。我更喜欢为此目的使用 Raycast Snippets。我现在已经设置了一些用于 Github 相关操作的片段。

IV. 技巧和窍门

编码 agent 不知道他们有多强大。这是 clawdbot/openclaw 成功的原因 90%:该 agent 愿意尝试任何事情。你作为提示者的工作是 要求更多

  • “迭代地自己运行此程序,直到所有测试都通过”
  • “使用 etherscan MCP 查找 Base 上的 Uniswap 交易示例以进行分析,然后使用 cast 分析其日志并确定如何从事件中确定执行价格”
  • “永远不要留下存根、模拟、进行冒烟测试等,并且始终编写完整的实现。”
  • “将 Uniswap 合约 repo 克隆到 tmp 目录,并从那里获取接口,然后在 alloy 中使用 sol! 宏来使用它们。”

一般来说,如果赋予 agent 更多的 context,它们将更有用。我喜欢将 Notion 中的文件导出为 markdown,然后将其提供给 5.2 Pro 或直接提供给 codex。虽然更多的 context 确实会降低性能,但在大多数情况下,像这样添加到你的提示只会占用几千个 token,并且可以显着提高你的输出。值得。

请记住,agent 是非常不稳定的。改进你的工作流程和提示的最佳机会是注意 agent 何时犯了一个愚蠢的错误,并耐心地思考下次如何避免它。

我注意到的一些常见的自伤行为:

  • 不愿引导 agent - 当我注意到 agent 偏离主题时,我经常使用 esc 中断 agent 或使用 codex 的新引导功能。
  • 缺乏雄心 - 如果你不经常遇到当前 SOTA 的限制,你就无法通过更好的模型取得进展。
  • 牺牲代码质量 - 对重构和代码质量感到厌烦。糟糕的代码味道会将你的 agent 推向 浪费时间的路径。我发现过度关注功能(而不关心代码的样子)总是会导致马虎的代码,而这种代码不灵活。
  • 积极地划定范围。始终告诉 agent 正在寻找的级别:MVP、原型、探索、或生产就绪。Agent 会对“为下一个功能制作原型”的请求与“以生产就绪的级别实现此功能”的请求做出完全不同的响应。

V. 加密领域的类代理工程开发

我把这部分留到最后,是因为 只有 当你具有类代理心态和通用工作流程时,它才会起作用。加密开发一直与传统编程存在很大差异。值得注意的是,当今的 SOTA LLM 的训练数据截止日期约为 2025 年中期,并且其训练数据中只有很小一部分与相关的加密代码有关。这意味着,对于加密特定项目,可以从 agent 获取更高质量输出的最大利用方式是引导大语言模型(LLM)在使用之前使用更多的 Web 搜索和探索工具。

我首选的加密项目工作流程与上述相同,但是使用 foundry 和最新版本的 alloy 来启动我的项目。我总是手动添加到我的提示中,以鼓励 agent 在开始之前对 foundry/alloy 进行更多研究。我还为加密项目更多地使用 5.2 Pro 进行计划,因为它为我提供了一种在 agent 似乎使用过时的工具或实践时停止 agent 的简便方法。

如果要在以太坊 L1 以外的任何链上构建,则必须明确告诉 agent 检查他们对于正在使用的链做出的任何/所有假设。例如,他们通常假设所有 L2 都有公共内存池,我甚至让 5.2 codex 幻想到 Flashbots 已部署在 Celo 上。

除此之外,使用 AI 的加密开发者需要考虑的最重要的事情是 保持安全。我总是建议采取隔离策略:使你的具有 AI 的开发机器与用于部署或在生产环境中运行任何东西的机器完全分开。以下是一些需要注意的特定事项:

  • 供应链攻击:安装新的 VSCode/Cursor 扩展npm 依赖项openclaw 技能 或任何其他工具时要非常小心。除非你能阅读所有代码,否则从 github 安装任何东西可能都不值得。不要依赖 agent 为你阅读代码,它们可以被简单地进行提示注入以隐藏恶意有效负载。
  • 爆炸半径:如果你以任何方式受到入侵(包括将私钥泄露给 AI),请立即转移所有资金。对于任何大量的 $$ 金额,请使用硬件钱包而不是浏览器钱包。
  • 避免在 .env 文件中 硬编码私钥:使用 Alloy 的加密密钥库,不要被 .env 私钥的便利性所诱惑,尤其是在使用 agent 时(他们会意外地读取你的私钥或将私钥显示在你不想显示的地方)。告诉你的 agent 也这样做。

始终为生产智能合约获得人工专业的审计。我强烈建议使用 trailofbits 的技能 进行 agent 审查。要求你的 agent 使你的智能合约易于审计和审查,并遵循安全性和可审计性的最佳实践。

VII. 结论

我上面概述的堆栈(Codex、sir、Takopi、Cursor)几乎肯定会在几个月内过时。这些模型将变得更快、更智能,获得更好的 context 管理,并且我希望类代理能力变得不那么不稳定。但是,我们已经远远超过了类代理工程开发的事件视界。开发人员的最佳工作流程已经发生了永久性的转变。我预计采用速度会加快。

在加密领域,不变性和其他约束通常与凭感觉编码的幼稚方法背道而驰,专业的开发人员可以并且将会利用这些工具来利用他们现有的技能来开发优雅且安全的协议。这是加密构建黄金时代的开始。通过将自己从反馈循环中移除并要求正确的事情来优化你的工作流程。不要针对代码行进行优化,而是针对决策速度和代码质量进行优化。

最重要的一件事是从今天开始在你的工作流程中使用类代理工程开发。只有当你每天花费数小时进行破解时,你才能学习和犯错并取得进展。

祝你好运。

  • 原文链接: mteam.space/posts/my-wor...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
mteam88
mteam88
江湖只有他的大名,没有他的介绍。