当我们谈论浏览器中的智能体（Agent）时，通常想到的是 Python 后端服务加上前端 JavaScript 调用 API 的架构。然而，一个更具前沿性的方向正在浮现 —— 让智能体直接运行在浏览器沙箱中，通过自复制代码形成网格（Mesh）网络，实现去中心化的协作与计算。这种架构的核心，是用 Forth 这门古老的栈式语言来构建轻量、可自举的智能体内核。

为什么选择 Forth 作为智能体内核语言

Forth 诞生于 1960 年代，其核心设计哲学是极简主义与可扩展性。它不追求抽象层次，而是提供一个可直接操作硬件或运行时环境的瘦中间层。这种特性使得 Forth 极其适合作为浏览器中智能体的底层解释器 —— 解释器本身可以压缩到几十 KB，解析和执行速度极快，且天然支持元编程（Metaprogramming），即程序可以修改自己的代码。

在浏览器环境中，这意味着一个基于 Forth 的智能体可以在运行时动态加载新词（Word，相当于 Forth 中的函数）、修改自身行为，甚至生成子智能体的代码。已有多个开源项目验证了这一可行性：sallied-forth 实现了在浏览器中运行的 Forth 类解释器，专注于 JavaScript 互操作；webForth 提供了完整的 Web 环境集成，包含交互式控制台；WASM-Forth 则尝试通过 WebAssembly 将 Forth 运行时编译为接近原生的执行效率。这些项目共同证明了一个事实 ——Forth 可以在浏览器中作为一等公民运行，而不仅仅是历史遗产。

自复制机制：从代码到代码的演化

自复制（Self-Replication）在智能体系统中并非新鲜概念，但将其落地到浏览器环境面临独特的约束。浏览器的同源策略（Same-Origin Policy）限制了不同标签页之间的直接内存访问，Service Worker 提供了一种沙箱内的后台执行机制，而 WebRTC 则为跨浏览器通信打通了管道。一个基于 Forth 的自复制智能体可以遵循以下路径实现代码繁殖：

首先，父智能体将自身的 Forth 源代码序列化为 JSON 或 Base64 字符串。这段代码包含了核心解释器、词定义表以及通信协议栈。序列化的体积通常可以控制在 50KB 以内，对于浏览器网络请求而言极为轻量。当智能体需要繁殖时，它通过 WebRTC DataChannel 或 POST 请求将代码推送给目标节点，目标节点收到后启动一个新的 Forth 解释器实例，将代码反序列化并执行，从而完成 “出生” 过程。

这种机制的精妙之处在于遗传变异：父智能体可以在序列化前的修改阶段引入微小变化 —— 例如调整通信端口、修改随机数种子、或者替换某几个词的实现。新生智能体因此拥有与父代相似但不完全相同的行为集合，从而实现一种受控的演化。关键参数包括变异概率（建议控制在 1% 以下）、代码校验和验证（使用 CRC32 或 SHA-256 防止传输损坏）、以及沙箱超时阈值（单次执行不超过 5 秒以防止无限循环）。

去中心化网格通信：节点发现与消息路由

网格（Mesh）网络的核心挑战在于节点发现、身份认证和消息路由。对于运行在浏览器标签页中的智能体网格，这三个问题都需要在 Web 平台的限制下找到工程化解法。

节点发现可以借助多种技术的组合。WebRTC 的 ICE（Interactive Connectivity Establishment）协议支持对等节点通过 STUN/TURN 服务器建立直接连接，天然适合去中心化拓扑。更轻量的方案是依赖一个已知的中继服务器列表，新启动的智能体在启动时查询该列表并尝试建立连接，之后逐步构建本地缓存的节点目录。值得注意的是，为了避免单点故障，中继服务器列表本身应该由智能体社区通过共识机制动态更新 —— 例如每个智能体每小时向随机三个已知节点报告自己的存在，超时未报告的节点从目录中移除。

身份认证方面，每个 Forth 智能体在启动时生成一个 Ed25519 密钥对，公钥作为节点标识。由于浏览器环境无法安全存储私钥（localStorage 对恶意脚本不设防），实际部署中通常将私钥托管在浏览器扩展的 secure storage API 中，或者每次启动时由用户通过密码解密后导入。签名验证确保了接收方可以确认消息来源，而无需依赖中心化的 CA 体系。

消息路由则可以采用简化的 Gossip 协议。每个智能体维护一个邻居节点列表（建议 3 到 7 个），当收到一条需要转发的消息时，随机选择邻居中的子集进行转发。这种机制的收敛速度约为 O (log N)，在节点数量为数千的网格中表现良好。实际部署时需要设置消息 TTL（建议 6 到 8 跳）和去重缓存（使用消息 ID 的 Bloom Filter），以控制网络带宽和计算开销。

监控指标与回滚策略

运行在浏览器中的自复制智能体网格需要一套完整的可观测性体系。以下是建议采集的核心指标：

  • 节点存活率：每分钟检查一次邻居节点的可达性，连续 3 次超时则标记为离线并从邻居列表移除。
  • 代码版本分布：统计当前网格中各版本智能体的占比，用于评估升级 rollout 的进度。如果某版本占比突然下降，可能存在致命 bug。
  • 消息吞吐量：每秒处理的消息数量，过高则触发流控（每个节点每秒最多处理 100 条消息）。
  • 资源占用：单个标签页的内存使用量不应超过 200MB，CPU 占用率瞬时峰值不应超过 50%。

回滚策略对于自复制系统尤为关键。推荐的做法是保留最近三个版本的代码快照，每个版本附带校验和和时间戳。当检测到某节点行为异常（例如消息丢失率超过阈值）时，网格中的其他节点可以协同投票决定是否将该节点隔离，并指示其回滚到上一个稳定版本。投票机制可以采用简单的多数决 —— 超过半数的邻居节点同意即执行回滚。

实践中的工程权衡

将 Forth 智能体放入浏览器并非没有代价。最主要的限制是浏览器的单线程模型 —— 所有智能体逻辑都在主线程或有限的 Worker 线程中执行，无法利用多核并行计算。这意味着复杂的人工智能推理（如大语言模型调用）仍然需要委托给后端服务，浏览器端的 Forth 智能体更适合承担轻量协调任务 —— 例如消息路由、状态同步、触发器检查等。

另一个权衡是安全性。浏览器沙箱虽然是天然的隔离层，但也意味着恶意代码一旦突破智能体逻辑，就可以访问存储在 localStorage 中的会话令牌、Cookie 和表单数据。因此，智能体网格的边界应该严格控制 —— 只允许运行经过审计的 Forth 代码片段，所有外部输入必须经过词法分析和边界检查。

小结

基于 Forth 的浏览器智能体网格代表了去中心化计算的一个实验性方向。Forth 的极简内核使得解释器可以做得足够小，序列化和自复制成为可能；浏览器的 WebRTC 和 Worker API 提供了跨标签页通信的底层能力；而网格拓扑则赋予了系统天然的容错和扩展性。当前这一方向仍处于早期探索阶段，工程化参数（如邻居节点数量、消息 TTL、变异率）需要在真实环境中反复调优，但其所蕴含的 “代码即生物” 的愿景，恰恰呼应了人工智能系统向自主化演化的长期趋势。

资料来源：