北京
此前，我们已经把一个智能体拆解成几个最小部件：模型负责判断下一步，循环保持流程向前推进，工具用来和真实世界交互，状态则把任务串联起来。这样一来，一个自然的问题就浮现出来——如果智能体已经有了模型、循环、工具和状态，为什么还要再谈哈尼斯？
更容易让人混淆的猜测是：哈尼斯是不是一个更高级、更聪明的智能体，专门用来管理其他智能体？这个想法听起来很合理，但它把架构引向了错误的方向。哈尼斯不是另一个智能体，不是一套更长的提示词，也不是某个框架的代号。它根本就是模型之外的控制系统。
继续拿那个小型的命令行智能体举例：用户说，帮我搞清楚这个项目的测试为什么失败，然后修好它。如果这个命令行智能体只是一个演示，事情可以很简单——把用户输入发给模型，模型要求读取文件，程序读文件，结果放回提示词，模型要求编辑文件，程序编辑文件，模型要求运行测试，程序执行测试。这一连串动作能跑通一次，已经看起来像一个智能体。
可一旦有人真正开始使用它，立刻就会冒出一堆问题：模型如果想执行 rm -rf 怎么办？它要是想读取用户主目录下的私有文件怎么办？跑了十分钟被用户中断，工作状态怎么保存？工具执行出错后，下一轮模型的上下文是该看完整日志，还是只看摘要？同样的任务明天继续，会话应该从哪里恢复？修改看上去成功了，却没有测试验证，系统怎么知道任务真的完成了？用户说智能体损坏了文件，我们要怎样回溯到底发生了什么？
这些问题都不属于模型本身，也不应该丢给模型去决定。模型只是在当前上下文中生成下一步的判断。权限、执行环境、会话生命周期、可观测日志、验证标准、治理策略——这些全都是模型外部的工程责任。合在一起，就是哈尼斯。
智能体在任务中判断下一步；哈尼斯则让每一步在真实环境中变得可执行、受约束、可观察、可恢复、可验证、可治理。框架也许会提供哈尼斯的某些部分，但哈尼斯更像是一组模型外部的工程职责集合，而不是一个包名或者产品名。一旦智能体能够调用工具，就必须把“模型提案”和“系统执行”区分开；系统执行需要权限、沙箱、预算和错误处理，而所有这些，正是哈尼斯的领地。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
