最新

我正在尝试自动化我们目前的一些手动流程，但仍然无法克服这个难关。我到底做错了什么？ 我正在使用这些人工智能API进行实际的处理工作，老实说，我感到沮丧和有些愤怒。这些人工智能公司向我们展示了一些宏大的自动化愿景，但实际使用他们的服务却是一种令人失望的体验。 1. 结果从来不一致。“请确保提取所有项目” -> [项目1, 项目2, 项目3, “字面意思是一个评论 // ...剩余项目”] 这是什么鬼！！有时它会给我一个完整的项目列表，有时却是这种胡扯。我提供了一个工具，但一半的时间它只抓取前三个，可能还会抓取最后一个（忽略中间的所有内容）。 2. 由于结果不可靠，我不得不进行更多的后处理。大约60%的时间，即使经过后处理，我也不得不拒绝，因为它们没有达到我的信心阈值。 3. 这些API的供应商支持很差。 - iOS有一些疯狂的行为，有时文件扩展名是.jpg或.JPG等。例如，OpenAI的API会因为扩展名不是“.jpg”而返回错误请求，所以我现在不得不添加更多代码，以确保用户上传文件时，我会重命名文件。 - 文档会说它支持一系列文件格式，但却因为不是.PDF而拒绝请求，尽管其目的为“助手”（文档中说可以处理图像）。没问题，我会转换一下。 - 处理来自其他来源（如G Drive等）的文件时，扩展名缺失但MIME类型存在……同样，错误请求。 4. 我们从2024年的“AGI即将到来”变成了今天的“人工超级智能即将到来”。我们能不能放松一下？我是不是掉进了营销陷阱？ 我认为大型语言模型（LLMs）在像Cursor这样的应用程序中，或者在客户支持中非常出色，因为它们不需要给出“完美”的回答，因为人类操作员会进一步提示它。你有多少次不得不处理Cursor的愚蠢输出（我是重度用户，每天都在处理这个）。RAG是一个很酷的应用程序，在我看来，那里的正确性或精确性并没有真正的必要。我有数百条我输入的笔记，有时会参考。我每次得到的答案都不同，但我并不需要它们是完美的。

你好，HN！我是来自Schub的Sebastian。 我们刚刚开源了我一直在开发的新项目，叫做legacy-use，我很想听听你们的想法。 在Schub，我们一直在构建能够自动化遗留Windows软件（如医疗系统、财务工具、电子健康记录）的代理，这些软件对业务至关重要，但自Windows XP以来几乎没有变化。这些应用程序没有API，通常需要人类全天候点击操作。 因此，我们开发了legacy-use，这是一个针对任何桌面应用程序的代理API层。严格来说，它适用于任何软件。legacy-use通过模拟鼠标和键盘输入来让AI代理控制基于GUI的软件，并提供完整的视觉反馈。就像UIPath，但更能容忍错误。它基于Anthropic的计算机使用技术，并扩展其功能以支持旧的遗留工具，适用于Windows、Linux或其他系统。 它的工作原理如下： - 我们构建基础设施以连接到遗留系统（如RDP/VNC + VPN），并处理排队 - 我们向目标系统执行提示，并处理所有日志记录和监控 - 我们允许代理提取数据并将其作为REST API暴露 - 我们内置了保护措施，以便在出现问题时可以调用人工操作员 我们已经看到了一些非常有趣的实际应用： - 一家医疗服务提供商使用GPT和legacy-use自动化了30%的行政工作 - 一家会计公司将其与2009年的财务应用连接，现在可以完全无人工干预地生成合规报告 让我感到兴奋的是：我们GDP中很多产生价值的行业依赖于遗留软件来运营业务。而且这种情况在短期内不会改变，因为这些软件是针对他们的特定用例开发的。因此，为了从代理革命带来的自动化中获利，他们需要开放他们的遗留系统。这就是我的愿景：允许访问任何现有的IT系统，以便公司能够参与代理革命。 这是我们的代码库：[GitHub链接在这里] 我非常希望听到你的反馈，如果你想开创一个用例，我也很乐意聊天。如果你有一些老旧的内部应用程序一直想要自动化，我很乐意帮助你搭建你的第一个流程。 让我们将遗留软件带入代理时代。 —— Sebastian

这是我正在开发的一个项目的演示。虽然还处于早期阶段，但请查看演示，并告诉我你的想法和反馈。

我一直在探索早期的Unix系统，特别是*PDP-7上的Unix V0*及其后继版本*PDP-11上的Unix V1*，并使用SIMH模拟器进行研究。 有趣的是，在这些早期版本中，现代最常用的shell命令之一`cd`并不存在。 - 在*Unix V0*中，目录的更改是通过一个名为`ch`的shell命令来完成的，结合一个特殊的目录`dd`（directory directory）使用。例如，要进入Ken的主目录，可以输入`ch dd ken`。这似乎反映出当时尚未实现完整的层次文件结构。我已经在SIMH模拟器中验证了这一行为。 - 在*Unix V1*中，方法变得更加熟悉：你可以使用`chdir /usr/ken`，但仍然*不是*`cd`。这一点在SIMH中也得到了验证。丹尼斯·里奇在《Unix时间共享系统的演变》中提到： > “顺便提一下，_chdir_被拼写为_ch_；我不记得为什么在转到PDP-11时要扩展这个名称。” 现在事情变得有趣了： 在阅读[Unix V0的shell源代码（`pbsh.s`）](https://github.com/DoctorWkt/pdp7-unix/blob/master/src/other/pbsh.s#L199C1-L210C18)时，我发现了一些似乎是在检查与字符串`"chdir"`匹配的内置命令的代码——但它比较的是前3个字符，而不是2个或5个： ```asm chdirstr: <ch>;<di>;<r 040 . . . . . " check for built-in "chdir" command lac argv0 sad chdirstr skp jmp 1f lac argv0+1 sad chdirstr+1 skp jmp 1f lac argv0+2 sad chdirstr+2 jmp changedir ``` 这个逻辑表明它会匹配像`chd`这样的字符串——因为只比较了前3个字符（`argv0`，`argv0+1`，`argv0+2`）。 然而，当我在SIMH中运行Unix V0时，我只能让`ch`工作——`chd`似乎并没有被识别为命令。这似乎与shell源代码所暗示的相矛盾。 有没有人见过`chd`在早期Unix shell中被记录或工作的情况？ 我很想听听其他探索过这一层Unix考古学的人的看法。