我构建了一个小型 Agentic 交易应用。它花了我几个小时和每次约 0.20 美元的成本。

Source: Dev.to

请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！

为什么启动这个项目

当我看到文章并听到人们谈论 AI 代理、编排框架和多代理架构时，我的第一直觉是：如果你会写代码，只需要几行代码、几次 API 调用和一个大语言模型。就这样。它就是你的代理。

我想检验一下这个直觉，于是把它和我真正关心的东西结合起来：交易.

期望的工作流程

思路很简单：一个应用程序，它

1. 从我这里获取一些输入（可选）。
2. 调用几个 API 来收集市场数据和新闻。
3. 将所有内容发送给 LLM，并提供正确的上下文。
4. 保存输出以供后续运行（一种基本的记忆形式）。
5. 通过电子邮件和推送通知将结果发送给我。

我不太愿意让它自动下单或取消订单——也许以后再考虑。现在我只想让它 思考 并告诉我它的想法。

应用实际功能

每次运行都会生成一个 具体的推荐，例如：

• WAIT
• 在特定价格（或 NOW）买入 BUY
• 在特定价格（或 NOW）卖出 SELL
• 修改已有订单，等等

这不是模糊的“市场看涨”——而是 附带理由的可执行下一步。我仍然会做最终决定，但模型负责把所有信息整合成一个决策。

实现细节

技术栈

核心流程

flowchart TD
    A[Start (cronjob)] --> B[Gather user input / manual overrides]
    B --> C[Fetch broker data (positions, pending orders)]
    C --> D[Pull news via Tavily]
    D --> E[Build prompt (dynamic variables inserted)]
    E --> F[Call Claude (Opus) via LangChain]
    F --> G[Generate run summary + recommendation]
    G --> H[Save summary to file (memory)]
    G --> I[Send email (Gmail) & push (Home Assistant)]
    I --> J[End]

为什么选择 LangChain？

• 部分是为了 学习它。
• 部分是因为我想在以后 扩展该解决方案（例如，将首次查询路由到 Sonnet，然后升级到 Opus）。
• 它是一个 便利的抽象层，而非严格的要求——所有操作都可以不使用它完成。

动态用户提示

该提示包含多个 运行时填充变量：

• 当前持仓
• 待处理订单
• 历史订单

这些变量通过对我的经纪商的普通 REST 调用进行填充——无需复杂的编排。

缺失的历史价格数据

我的经纪商没有通过其 API 提供历史价格数据，而且我不想支付额外的数据提供商费用。

目前该提示 并不严重依赖价格图表或技术指标。相反，它依赖于：

• 新闻
• 市场评论
• 分析师观点（全部由 Tavily 拉取）

这使得系统 简单且低成本。我以后会添加历史数据来源。

本地覆盖模式

当应用在本地运行（而不是作为 cronjob）时，我可以：

• 粘贴手动新闻项。
• 强制设定特定乐器价格（例如，“假设价格 = X”）。

这在测试和“假设”情景中出奇地有用。

Memory (Run‑to‑Run Context)

• 我不存储整个 LLM 输出。
• 系统提示要求模型生成 “运行摘要”——其推理和建议的浓缩版本。
• 该摘要保存到文件中，并 注入到下一个提示 中。

Result: 模型可以看到上一次的结论、推荐内容以及条件是否已发生变化。没有向量数据库、嵌入或检索管道——仅仅是一个纯文本文件。

通知

• Email: 我的 Gmail 账户向我自己发送邮件。
• Push: Home Assistant 已经会向我的手机推送，所以我直接调用它的 API。

两者都简单、可靠，并且已经在我的环境中运行。

成本

• LLM 使用: 每次运行约 $0.20（Claude API 用于获取上下文、读取新闻、推理并生成推荐）。
• 新闻数据: Tavily 的免费 Researcher 级别（对我当前的月运行次数来说绰绰有余）。

唯一真正的成本是 LLM。专业交易员可能会进一步优化（本地模型、微调的金融模型、延迟问题），但对我来说已经足够。

结束思考

• 对某些步骤使用本地模型。
• 寻找针对金融推理微调的模型。
• 优化延迟和成本。

但对我而言，当前的设置提供了一个可重复、可审计且低成本的决策支持工具，正好满足我的需求：思考、推理并告诉我该怎么做——同时我保留最终的决定权。

Fun and Learn

免责声明： 这只是个人学习项目。此处内容不应被视为金融建议。作为非母语英语使用者，我使用了大型语言模型（LLM）来审阅并润色语言，同时保留了我的原始语气和想法。

端到端概览

1. Cronjob 在 K3s（Raspberry Pi 5） 上触发 Docker 容器。
2. Broker API 调用获取当前持仓、挂单以及订单历史。
3. Tavily tool（通过 LangChain）获取相关的市场新闻。
4. 提示组装： 将所有动态数据（包括上一次运行的输出作为记忆）注入用户提示中。
5. Claude Sonnet 处理完整上下文并生成推荐。
6. 输出 保存到文件（作为下次运行的记忆）。
7. 电子邮件 + 推送通知 将推荐发送给我。
8. 人机交互环节： 我决定是否依据模型的推荐采取行动。

这就是八个步骤。大多数步骤仅是 API 调用和字符串拼接。真正“具备代理性”的部分是第 5 步——LLM 在拥有工具访问权限的结构化上下文中进行推理。第 8 步则只是一个人在咖啡旁查看手机而已。

为什么（或为什么不）使用花哨的编排框架？

显而易见的问题： 对于能够写代码的开发者来说，为什么一定要使用花哨的编排框架来构建这样的系统？

“无代码”AI 代理和可视化流水线有其市场，但如果你真的写代码，核心要素只有：

• 一个 LLM API
• 若干 REST 调用（经纪商、新闻、通知等）
• 用于提示的 字符串模板
• 一个 文件系统（用于记忆）
• 一种 发送通知 的方式（邮件、推送等）
• 一个 容器运行时（可选，但很方便）
• 日志记录（如果需要审计或调试数据）

仅此而已，这就是代理。

我并不是说 LangChain 必须使用。我之所以使用它，是因为想学习它，并且它对 Tavily 的集成抽象非常方便。我完全可以用原始 API 调用和几百行 Python 代码实现同样的功能。

编排本质上就是代码。 它一直都是如此。

LLM 代理的价值体现在：

• 提示设计
• 上下文组装
• 模型推理的质量

其他一切都是管道工作，而开发者已经在这条管道上工作了数十年。