我想分享一个观察到的瞬间，算是一个灵光一现的想法。
我遇到的大多数声称自己在“做REST”的开发团队，实际上并没有遵循HATEOAS。根据Roy Fielding的严格定义，他会认为这“并不是真正的REST”。（不过不要被这个话题分散注意力，我不想陷入那个纯粹主义的争论中。）
许多团队没有实施HATEOAS的原因在于，它要求API客户端具备智能和适应能力。客户端需要自行发现“我接下来可以做什么”，并运用逻辑来选择下一步。但许多团队面临紧迫的时间压力，因此将REST简单地理解为“通过HTTP传输JSON，并使用一致的URL模式”要容易得多。
有趣的是：引入大型语言模型（LLM）后，HATEOAS的潜力得以释放。LLM可以做到“愚蠢”的API客户端无法做到的事情：询问“我接下来可以做什么”，然后利用推理来理解这些选项并选择其中一个。
返回首页
最新
厌倦了看到这些充满氛围的网站，我们创建了一个地方，让它们彼此竞争，以抵御来自旧时代人群的怒火。<p>我们承诺会有激烈的竞争，我们承诺会有影响力——追求永恒的荣耀就靠你自己了。<p>保证会崩溃（不可退款）
... 是在四年前推出的吗？<p>(《卡利斯托协议》)。<p>这是个严肃的问题。广告商是预付了大量的展示次数吗，还是怎么回事？
嗨，HN！<p>我是一个名为 Jido 的 Elixir 代理框架的作者。我们本周发布了 2.0 版本，推出了一个经过生产环境验证的框架，用于在 BEAM 上构建、管理和运行代理。<p>Jido 现在支持一系列代理功能，包括：<p>- 工具调用和代理技能
- 在分布式 BEAM 进程中全面支持多代理及监督
- 多种推理策略，包括 ReAct、思维链、思维树等
- 高级工作流能力
- 通过强大的存储和持久性层实现耐用性
- 代理记忆
- MCP 和传感器与外部服务接口
- 深度可观察性和调试能力，包括完整的 OTel 堆栈<p>我知道代理框架可能被认为有些过时，但在 BEAM 上还没有出现过重大框架发布。随着越来越多的人意识到 BEAM 架构与代理工作负载的良好匹配，现在正是发布的好时机。<p>我的背景是企业工程、分布式系统和开源。我们拥有一个强大且不断壮大的 Jido 生态系统建设者社区。我们期待在 Jido 上构建的各种应用！<p>欢迎与我们一起构建代理！
这是我几乎工作了一年的项目——echo.html！它是一个用于记录笔记、连接笔记并将其保存/分享为单个文件的工具。想象一下，它结合了Feather Wiki和Roam的特点，但使用类似于emacs的命令。希望你会喜欢！
我想分享一个我正在进行的项目。和许多人一样，我对现有的投资组合应用感到沮丧。它们优先考虑多资产的行情列表，充斥着各种山寨币的信息，且常常会收集你的投资组合数据。
我找不到一个专注于比特币的干净、专用的应用，所以我决定自己动手开发一个。
从一开始，我的核心架构原则就是：你的数据属于你：
100% 本地存储：你的投资组合余额、地址和交易历史完全存储在你的设备上。没有用户数据被发送到外部服务器。
无托管，无执行：这只是一个分析和跟踪工具。你完全掌控一切。
开放数据源：它仅使用开放的API获取价格和网络状态。在第三方API缺少历史数据的情况下，应用会在本地缓存和积累数据，以生成你的指标。
由于该应用不需要担心一万种不同的代币，它完全专注于长期比特币持有者真正关心的工具和智能：
灵活的投资组合跟踪：你可以手动添加交易，上传CSV文件，或直接从公共钱包地址导入（并能够选择特定交易）。
准确的盈亏：编辑成本基础、费用和备注等元数据，以准确了解你的投资组合表现和回撤情况。
本地网络统计：直接在应用中跟踪区块高度、内存池压力、交易费用、流通供应量和减半倒计时。
积累目标：设定你的持仓目标并直观跟踪你的进展。
基本功能：干净的互动图表、可自定义的价格提醒（带完整触发历史）以及快速更新的主屏幕小部件。
核心跟踪功能完全免费。还有一个可选的PRO级别，解锁高级技术分析、标准普尔500/黄金相关性跟踪和企业财务监控等功能（这有助于支持开发），但主要目标是提供一个稳固、无噪音的基础。
我希望这里的社区能够深入探讨，测试一下，并告诉我你们的想法。你觉得当前生态系统中还缺少哪些严格的比特币原生功能？
嗨，HN，
我开发了DevOps Agents——一套专门的AI代理，旨在帮助处理日常的DevOps和SRE工作。
这些代理会分析你的GitHub仓库，确定所需的云资源，部署所有内容，并使你的应用程序上线到生产环境中。它们具有聊天界面（类似于Claude Code或ChatGPT），在部署后会继续协助你管理基础设施。例如，我可以询问代理应用程序是否正在运行，它会通过SSH连接到资源，检查状态、查看日志、找出根本原因，并使应用程序恢复运行。
我已经在涉及复杂设置的各种任务中使用过这个工具——Kubernetes、ELK栈、Grafana、Prometheus、Redis、ClickHouse、CI/CD管道、自托管工具、Docker设置，以及多账户的AWS、Azure、GCP或DigitalOcean部署。
我之所以构建这个工具，是因为我已经在使用Cursor和Claude Code来管理我的基础设施，它们在代码方面表现出色。但基础设施是不同的——大多数上下文并不在代码中。比如配置文件的位置、哪个云账户对应哪个环境、哪些端口是开放的、服务之间如何通信——这些信息都存在于代码库之外。每次我开始一个新会话时，都要从头重新解释我的整个设置。这些代理是专门设计的，能够在会话之间保留基础设施的上下文，这样我就可以继续管理我的基础设施而不失去连续性。
欢迎提出任何问题。