一周热榜

嗨，HN， 我和我的朋友一直在尝试使用大型语言模型（LLMs）来分析生物技术股票。与许多其他行业不同，生物技术交易主要是事件驱动的：FDA的决策、临床试验结果、安全更新或试验设计的变化都可能导致股票在一天内上涨三倍（[链接](https://www.biotradingarena.com/cases/MDGL_2023-12-14_Resmetirom_NASH)）。 解读这些“催化剂”，通常以新闻稿的形式出现，通常需要具备生物学或医学背景的分析师。听起来“积极”的催化剂，如果出现以下情况，仍然可能导致抛售： - 效果大小低于预期 - 结果仅适用于狭窄的子群体 - 终点指标未能有效降低后期阶段的风险 - 结果未能实质性改变批准的概率 为了探索这一点，我们建立了BioTradingArena，这是一个评估LLMs如何解读生物技术催化剂并预测股票反应的基准。基准测试仅提供催化剂和新闻稿发布前可用的信息（试验设计、先前数据、PubMed文章和市场预期），以测试模型在催化剂发布时预测股票走势的准确性。 目前，该基准包含317个历史催化剂。我们还为特定适应症创建了子集（在肿瘤学中规模最大），因为不同的适应症通常具有不同的模式。我们计划在接下来的几周内向公共数据集中添加更多催化剂。该数据集涵盖不同规模的公司，并创建了调整后的评分，因为大盘生物技术公司的波动性通常远低于小盘和中盘公司。 每行数据包括： - 真实的历史生物技术催化剂（1-3期结果、FDA行动等）及催化剂前一天和当天的定价数据 - 相关的临床试验数据和PubMed PDF 需要注意的是，我们的方法可能存在一些明显的问题。首先，许多临床试验新闻稿可能已经包含在LLMs的预训练数据中。虽然我们尝试通过“去标识化每个新闻稿”并仅提供催化剂日期之前可用的数据来减少这一点，但显然对于这是否足够仍存在一些不确定性。 我们一直在使用这个基准测试提示策略和模型家族。到目前为止，结果喜忧参半，但有趣的是，我们发现最可靠的方法是使用LLMs量化定性特征，然后对这些特征进行线性回归，而不是直接预测价格。 只是想和HN分享这个。我为那些想在沙盒中玩耍的人建立了一个游乐场链接。期待听到一些想法，希望大家能玩得开心！

嘿，HN， 我是一名转行的量化物理学家。我和一些朋友“构建”了SymDerive，因为我们希望有一个符号数学库，设计上是“代理原生”的，同时又是一个对人类实用的工具。 这归结为两个主要目标： 1. 代理可靠性：我发现，当AI代理遵循无状态的函数式管道（类似Lisp风格）时，它们编写的代码要可靠得多。这可以防止它们产生状态变化的幻觉或在长的过程脚本中迷失。我希望有一个库默认强制执行“输入 -> 转换 -> 输出”的流程。 2. 缓解向Python的过渡：对于许多物理学家来说，Mathematica是他们的母语。我想提供一种方式来缓解这一过渡——提供一座桥梁，保持熟悉的语法（驼峰命名法、Sin、Integrate），同时在底层严格使用Python科学栈。 我构建的内容：这是一个围绕标准栈（SymPy、PySR、CVXPY）的函数式封装，作为一个独立的引擎，适用于任何人——无论是人类还是代理——喜欢基于管道的工作流程。 ```python # “管道”方法（对代理更清晰，对人类可读） result = ( Pipe((x + 1)**3) .then(Expand) .then(Simplify) .value ) ``` “氛围”特性： - Wolfram语法：Integrate、Det、Solve。如果你懂数学，你就懂这个API。 - 模块化：重的功能（符号回归、凸优化）是可选安装（[regression]、[optimize]）。除非你要求，否则不会膨胀你的虚拟环境。 - 物理工具：我添加了我实际使用的工具——广义相对论的抽象指标符号、因果模型的克拉默斯-克罗尼希等。 这绝对是有主见的，但如果你正在构建代理来进行严格的数学计算，或者只是想要一个熟悉的函数式接口来进行自己的研究，这可能会有所帮助。 我发现协调者（Claude Code等）在学习工具和将任务发送到正确角色方面相当不错，我们对它的效果感到惊讶。 代码库在这里：https://github.com/closedform/deriver 如果被嘲笑得太狠我会哭的。

你好，HN。 我想首先说明，我是一名开发者，开始这个研究项目是为了挑战自己。我知道像MCP这样的标准协议是存在的，但我想探索一条不同的道路，并享受为桌面应用程序创建专门通信层的乐趣。 这个项目旨在以一种自主的方式处理桌面应用程序之间的通信，因此重点严格放在这个进程间通信（IPC）层上（忘记HTTP API调用吧）。 RAIL（远程代理调用层）的核心有两个基本概念。名字可能听起来有些吓人，但请记住这是一个研究项目： 内存逻辑注入 + 反射 范式转变：聊天是服务器，应用程序是客户端。 为什么采用这种方法？这个想法是避免创建庞大的包装器或API端点，仅仅为了调用内部方法。相反，代理应用程序将其自己的实例传递给SDK（例如，RailEngine.Ignite(this)）。 我发现以下流程非常有趣： - 应用程序将其实例传递给在其自身进程中运行的RailEngine库。 - 聊天（协调者）接收可用方法的清单。模型决定该做什么，并通过命名管道将命令发送回去。 - 触发器：应用程序中的RailEngine接收到命令，并对持有的实例使用反射直接执行.Invoke()。 本质上，我是通过SDK将“代理逻辑”直接注入到应用程序的内存空间中，使聊天能够远程触发本地方法。 关于代码库的说明：GitHub仓库已经变得庞大。核心关注点是RailEngine和RailOrchestrator。你会发现其他连接器（C++、Python），坦率地说，它们是“垃圾代码”或不完整的实验。我在C++中强行使用RTTR实现反射，但对此并不太满意。请跳过这些，它们与架构讨论无关。 我希望能将讨论集中在内存管理语言（如C#/.NET）上，并请教你们： - 架构：这种反转的架构（应用程序通过IPC“拨打回家”）对于本地代理来说，与标准的服务器/API模型相比是否有意义？ - 性能：关于每次调用都使用反射——是否值得在启动时实现一个机制，将方法缓存为委托？还是考虑到LLM本身的延迟，这种优化无关紧要？ - 安全性：由于我们实际上绕过了API层，假设的安全层应该是什么，以防止恶意使用？（例如，用户签名的能力清单？） 我很想听听关于架构的比较和批评。

我建立了一套 webhook 技能，因为 AI 编码代理在 webhook 集成方面的表现令人惊讶地糟糕。生成的代码看起来合理，但一旦运行，就会出现签名验证失败、原始请求体处理错误或中间件顺序破坏一切的问题。 PostHog 对 LLM 代码生成的研究（[链接](https://posthog.com/blog/correct-llm-code-generation)）发现，当代理参考已知有效的示例时，生成的代码更可靠，而不是从训练数据中重构。这就是这里采用的方法。 `webhook-skills` 是基于 Agent Skills 规范（agentskills.io）构建的一套特定于提供商的 webhook 实现和最佳实践指南： ``` - 可运行的示例（目前支持 Express、Next.js、FastAPI，未来将增加更多框架） - 记录了特定于提供商的签名验证注意事项 - 最佳实践模式：幂等性、错误处理、重试逻辑 - 启动时支持 11 个提供商（Stripe、Shopify、GitHub、OpenAI、Clerk、Paddle 等），将根据我的需求或请求进行扩展。 ``` 示例： ``` # 列出技能 npx skills add hookdeck/webhook-skills --list # 安装技能 npx skills add hookdeck/webhook-skills --skill stripe-webhooks --skill webhook-handler-patterns ``` 该工具与 Claude Code、Cursor、Copilot 兼容。这些示例即使没有代理也很有用：您可以直接复制的最小化、经过测试的处理程序。 欢迎提交 PR 以支持新的提供商和框架。我还构建了一个 AI 驱动的生成器，可以自动创建新的提供商技能。只需指向 webhook 文档，它就会研究签名方案，为每个框架生成验证代码，编写测试，并打开一个 PR。

最初是行动运行器未能接收新任务，现在已经扩展到其他服务。 - https://www.githubstatus.com/<p>之前无法发布此信息，因为它被标记为上个月事件的重复。

关于加州预算和一些提议的税收政策，已经进行了很多讨论，因此我请Claude Code对预算进行研究，并将其转化为一个互动仪表板。 通过使用异步子代理，Claude能够同时研究大约十个预算项目，涵盖多个年份，为像我这样对预算了解不多的人提供了大量有用的背景信息和图表。 虽然在前端更改方面仍然存在一些困难，但在研究方面，这大约提高了我20到40倍的工作效率。 如果你有任何想要添加的额外数据或可视化内容，请告诉我！