最新

尊敬的 HN 社区，我有一个问题：纯手工编写代码是否还有意义？让我来详细说明一下。 首先，我并非指那些需要“快速迭代”或强制使用大型语言模型（LLM）的环境。我更倾向于指那些你可以按照自己的意愿，而不是雇主的意愿来工作的环境。 其次，我不是指那种“帮我构建下一个 Twitter 克隆”的提示，而是指在你完成初步设计后，针对非常小的任务进行提示，例如：“创建一个添加列 [x] 的数据库迁移，该列不允许为空”、“在此表单中添加一个字段，该字段接受字符串值，并在后端根据此格式进行验证，然后将其保存到列 [x]”。基本上，就是用通俗的英语编写代码。 我为什么会问这个问题？我认为自己动手编写代码有助于更好地学习，但同时，如果你已经完成了所有的思考，现在只是通过提示来获得一个花哨的自动补全，那么我们可以说最困难的部分（设计）已经完成了，而你只是为了写而写，跳过了实际的编写过程。另一方面，我担心如果我停止在仍然可以手工编写代码的环境中这样做，我将失去思考代码和理解代码的能力。 您对此有何看法？

各位 HN 的朋友，我们是 Nitish 和 Prateek，Coasty（<a href="https:&#x2F;&#x2F;coasty.ai&#x2F;computer-use">https:&#x2F;&#x2F;coasty.ai&#x2F;computer-use</a>）的创始人。我们正在构建能够完成遗留桌面软件和 Web 应用程序内部工作流程的计算机使用代理，而无需可用的 API。 开发者可以通过我们的消费者应用程序或 API 向 Coasty 发送自然语言任务，选择机器或浏览器环境，并提供任何相关的凭据或文件。然后，代理通过屏幕截图、鼠标和键盘输入来操作界面，验证结果，并返回一个包含屏幕截图、操作、输出和错误的结构化运行记录。 这是一个代理在遗留应用程序中完成工作流程的原始演示（这是一个模拟）：<a href="https:&#x2F;&#x2F;drive.google.com&#x2F;file&#x2F;d&#x2F;1ZghU_3vsAYhHVz1bsvE0pkvZYk7OUnb1&#x2F;view?usp=sharing" rel="nofollow">https:&#x2F;&#x2F;drive.google.com&#x2F;file&#x2F;d&#x2F;1ZghU_3vsAYhHVz1bsvE0pkvZYk7...</a> 许多重要的软件仍然难以自动化。医疗团队通过支付方门户提交事先授权，会计团队将数据输入桌面应用程序，运营团队在内部系统、电子表格和远程桌面之间移动信息。其中许多应用程序没有 API、API 不完整，或者集成需要数月才能构建。 通常的替代方案是 RPA，即记录一系列点击并重放。当界面和工作流程可预测时，这会奏效，但当按钮移动、弹出窗口出现、页面加载缓慢或应用程序进入意外状态时，它通常会失效。 Coasty 采取了不同的方法。代理观察当前屏幕，决定采取什么行动，执行它，然后观察结果状态，然后再继续。它不需要 DOM 访问、辅助功能树、选择器或特定于应用程序的集成，因此相同的 API 可以操作浏览器、远程桌面和旧版 Windows 应用程序。 简化的请求大致如下所示： ``` run = coasty.runs.create( environment="vm_123", task=""" 在计费门户中打开患者记录。 输入附加的授权数据。 如果成员 ID 或程序代码不匹配，则不要提交。 返回确认号码。 """, files=["authorization.pdf"], approval_required=["final_submission"] ) ``` 响应包括最终状态、提取的输出、重放 URL 和带时间戳的事件日志： ``` { "status": "completed", "output": { "confirmation_number": "PA-184392" }, "replay_url": "...", "events": [ { "type": "verification", "field": "member_id", "result": "matched" } ] } ``` API 还可以暂停运行以供人工审批，从检查点重试，或者在遇到工作流程未预料到的情况时将控制权交还给开发人员。 我们去年夏天开始着手这项工作，因为我们看到模型在视觉方面越来越好，但却看到了计算机使用演示与生产工作流程所需可靠性之间的差距。让代理一次性完成一项任务相对简单。让它重复这项任务、从意外状态恢复、避免静默输入错误数据并提供其所做工作的证据则要困难得多。 我们在底层计算机使用模型周围构建了几个层。该系统跟踪工作流程的预期状态，检测应用程序何时偏离该状态，并可以重新规划而不是盲目继续。开发人员可以定义不变量，例如“患者姓名必须与源文档匹配”或“绝不在未经批准的情况下提交”，代理会在运行期间检查这些条件。 每次运行都在隔离的虚拟机中进行。我们公开了用于配置环境、上传文件、启动任务、流式传输事件、插入人工审批以及检索完整重放和审计跟踪的 API。当应用程序具有漫长的登录流程或持久的本地状态时，可以在运行之间保持环境的活动状态。 我们仍在努力解决的一个问题是速度与可靠性之间的权衡。代理可以通过减少观察和验证步骤来更快地移动，但在涉及患者记录、付款或监管文件的工作流程中，这会变得有风险。我们目前倾向于执行速度较慢但检查更多的操作，并允许开发人员配置审批点和验证策略。 我们最初与医疗运营团队合作，因为他们的工作流程结合了许多最困难的条件：支付方门户、EHR、PDF、电子表格、远程桌面以及会产生昂贵静默错误的动作。我们还通过开发人员 API 向构建自己的代理和垂直自动化产品的团队公开相同的基础设施。 我们目前根据代理运行时间和工作流程量收费，专用环境和企业部署有单独的定价。 我们特别希望得到那些构建和/或使用过浏览器代理、RPA 系统、桌面自动化或代理基础设施的人的反馈。我们想知道您希望直接控制 API 的哪些部分，您更喜欢哪些更高级别的抽象，以及在您自己的自动化系统中哪些故障模式最难处理。 如果您在自动化此类软件时遇到过奇怪的故障模式，我们希望听到您的意见。我们今天全天都在这里回答问题和做笔记！

嗨 HN！我之前在 2019 年（[https://news.ycombinator.com/item?id=19834681](https://news.ycombinator.com/item?id=19834681)）和 2023 年（[https://news.ycombinator.com/item?id=38252963](https://news.ycombinator.com/item?id=38252963)）都发布过 SirixDB。 SirixDB 的核心理念是，历史是一个一等公民。每次提交都会存储一个轻量级、可查询的版本。您可以查询任何时间点，甚至单个节点（例如 JSON 值），比较任意版本之间的差异，并高效地跟踪数据如何演变，而无需重放事件。 与传统的事件存储不同，历史状态不需要通过重放事件来重建，我们也不必考虑投影。版本是直接可查询的。 一个简单的例子： 1 月 1 日：记录“价格 = 100 美元，1 月 1 日生效”。存储于 1 月 1 日（交易时间）。 1 月 20 日：发现 1 月 1 日的价格实际上是 95 美元。提交更正。 更正后，您可以跨两个维度进行查询： - “我们认为 1 月 16 日的价格是多少？” -> 100 美元（交易时间） - “1 月 1 日的价格是多少？” -> 95 美元（生效时间） 自 2013 年以来，我一直在业余时间从事这项工作，追随康斯坦茨大学的学术前身（Idefix/Treetank）。该架构依赖于一个仅追加的物理日志和一个持久的写时复制页三元组。 架构的概览： 物理日志（仅追加，顺序写入） ``` ┌────────────────────────────────────────────────────────────────────────┐ │ [R1:Root] [R1:P1] [R1:P2] [R2:Root] [R2:P1'] [R3:Root] [R3:P2'] ... │ └────────────────────────────────────────────────────────────────────────┘ t=0 t=1 t=2 t=3 t=4 t=5 t=6 → 时间 ``` 每个版本都经过索引，未更改的页面是共享的： ``` [Rev 1] [Rev 2] [Rev 3] │ │ │ ▼ ▼ ▼ [Root₁] [Root₂] [Root₃] │ │ │ │ │ │ │ └─────────┐ │ └────────┐ │ └─────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ P1 │ │ P2 │ │ P1' │ │ P2' │ └──────┘ └──────┘ └──────┘ └──────┘ Rev 1 Rev 1+2 Rev 2+3 Rev 3 (共享) (共享) ``` 根页面下方是节点和二级索引，使用一种新颖的滑动快照算法来平衡读/写性能。所有内容都可以通过 Brackit 编译器使用 JSONiq 进行查询。 早在 2019 年，甚至在 2023 年，SirixDB 都因为 GC 压力而非常慢。与大多数其他文档存储不同，SirixDB 存储细粒度的节点，我意识到由大量小对象组成的堆上（JVM）表示根本没有意义。我使用 async-profiler 进行了测量——在 Andrei Pangin 本人的帮助下——结果是吞吐量低下是由于分配量巨大，该分配量几乎与打开的事务数量成线性关系。 由于我全职从事软件工程工作，我没有精力在业余时间进行大规模的重写。大约一年前，我开始尝试使用 AI。事实证明，AI 非常适合自动化将存储层迁移到 Java 的 Foreign Function & Memory API 的繁琐、重复部分，将页面完全存储在堆外。 展望未来，仅追加、不可变的页面设计自然地映射到 S3 等对象存储和 Kafka 等分布式日志，用于云版本，并且已经存在初步的原型。也许有一天它会成为一项商业服务，但目前，我很高兴看到这些核心设计原则终于得到验证。 有一个交互式演示、文档，代码在 GitHub 上。我很乐意听取反馈并回答问题！ 此致， Johannes [1] [https://sirix.io](https://sirix.io) | [https://github.com/sirixdb/sirix](https://github.com/sirixdb/sirix) [2] [https://sirix.io/docs/architecture.html](https://sirix.io/docs/architecture.html) [3] [https://demo.sirix.io](https://demo.sirix.io) [4] [https://sirix.io/docs/](https://sirix.io/docs/) [5] [http://brackit.io](http://brackit.io)

今天我用自己的工具扫描了整个 Django 仓库，它用了 2.5 分钟就完成了索引，并为我搜索的每个函数生成了完整的图谱。看到自己亲手构建的东西能够正常工作，总是令人无比激动。T-T