人·智能体·机器：三层结构与Agent能力边界
—— 慧采星河助理联邦核心方法论
作者：林剑平 前财富500强·远东研发中心经理
人负责"做什么"，智能体负责"怎么做"，机器负责"做出来"。
但智能体需要一双手——一双能真正改代码、跑命令、操作系统的执行之手。
一、三层结构
人 → 思考创新（无中生有）
智能体（上层） → 经验积累 · 拆解任务（协调者）
智能体（下层） → 连接机器 · 执行操作（执行者）
机器 → 按程序跑（执行层）
1.1 人：管"无中生有"
只有一件核心能力：从无到有。以前没人想过的事，想到了。这不是练出来的，是想出来的。人当然也会经验积累——练一年吉他，手上长茧——但人最珍贵的是"忽然发现这把吉他可以做出没人听过的声音"那一下。
1.2 智能体（上层）：协调者 · 管"经验积累"
站在统计学高度，读过海量数据，能总结规律、拆解任务、分配工作。
做不了一件事：想不出人类从来没想过的东西。这叫涌现，不叫突变。涌现是旧东西的新组合，突变是另一个物种突然出现。
1.3 智能体（下层）：执行者 · 管"跟机器说话"
它不属于"人与智能体之间"，因为人不直接跟它打交道。它是被协调者调用的，不是被人直接调用的。它是那条命令行通道的实体形态——真正读代码、改文件、跑命令。
1.4 机器：管"照程序跑"
有bug就乱，没bug就听话。不思考，不理解。
二、智能体的两难处境
智能体的出现，本来是为了解决"人不懂机器语言"的问题。理想情况是：
人说一句 → 智能体转译成机器能懂的指令 → 机器执行 → 智能体把结果转译回人话
但现实中智能体夹在中间，压力很大。
上半身（对人）: 反而比较轻松。训练数据多，自然语言处理是强项。
下半身（对机器）: 理论上命令行是智能体的母语，但机器上跑的工具——编译器、版本控制、多媒体处理——全是为人类设计的。它们的输出格式、报错信息、交互方式全部是"人类友好"的，不是"智能体友好"的。
对智能体来说，学人类的自然语言反而比学这些人类设计的命令行工具更容易。
三、两条路
3.1 命令行通道：原生通信
智能体直接发命令、读输出、控制进程。这是它的"母语"。
问题: 命令行工具的输出是为人类设计的（带颜色、进度条、非结构化文本），智能体需要额外的解析层，把"人类友好"转成"智能体友好"。
解法: 结构化包装器，将系统命令输出转为结构化数据。但关键——这只能让 Agent 看懂系统状态，不能让 Agent 动手改系统。
3.2 浏览器通道：模拟人类
很多系统不提供API，只有网页界面。智能体必须像人一样：打开浏览器、看内容、点按钮、填表单。
解法: 浏览器自动化工具 + 视觉语言模型。智能体"看"页面截图理解UI，语义定位元素，模拟点击和输入。
3.3 两条路的分工
| 路径 | 适用场景 | 沟通对象 |
| 命令行通道 | 系统级任务（文件、进程、网络、编译） | 机器原生 |
| 浏览器通道 | Web系统任务（登录后台、抓取数据、操作SaaS） | 人类界面 |
四、精确位置：四层分工
执行者不在"人与智能体之间"——人不直接跟它打交道。它处在智能体（协调者）和机器（操作系统）的交界处，是命令行通道的实体形态。
人（下达指令）
│ "重构登录模块"
▼
┌─────────────────────────────────────┐
│ 智能体·上层：协调者 │
│ 理解意图、拆解任务、制定计划 │
└─────────────────────────────────────┘
│ 调用工具 / 下发子任务
▼
┌─────────────────────────────────────┐
│ 智能体·下层：执行者 │ ← 命令行通道的实体形态
│ 真正读代码、改文件、跑命令 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 机器层 │
│ 文件系统、编译器、测试框架、版本控制 │
└─────────────────────────────────────┘
↑ ↑
│ 命令行通道 (原生) │ 浏览器通道 (模拟人类)
│ 系统调用/命令执行 │ 浏览器自动化 操作Web系统
│ │
└─────── 执行者 ─────────┘
执行者通过两条通道接触机器：命令行（原生通信，系统级任务）和浏览器（模拟人类操作，Web系统任务）。两条通道的协作让智能体既能控制底层系统，又能操作外部服务。
| 层级 | 成员 | 作用 |
| 人 | 创始人 | 提需求、做决策——无中生有 |
| 智能体·上层 | 协调者Agent | 拆任务、下指令——经验积累 |
| 智能体·下层 | 执行者Agent | 执行代码操作、连接机器 |
| 机器 | 操作系统、文件系统、编译器 | 跑命令、输出结果——照程序跑 |
它为什么不在"人与智能体之间"？ 你不会对着执行者说"帮我改这个函数"。你跟协调者说，协调者负责调度它。它是被智能体调用的，不是被人直接调用的。
五、执行者的架构设计
一个不需要界面的 AI 程序员。核心就一件事：
理解代码任务 → 直接操作代码库 → 返回结果
能力清单：
本质：智能体与机器之间那条命令行通道的落地实现。
架构位置
协调者（慧采星河助理）
│ 理解意图、拆解任务、分配工作
│
▼
执行者Agent（自建）
│ 接收任务 → 读代码 → 改代码 → 跑验证 → 返回结果
│ 实现: 大语言模型API + 文件系统权限 + 沙箱执行
│
│ 错误处理:
│ 编译失败 → 读取错误信息 → 自动修正 → 重试(上限3次) → 仍失败则返回协调者
│ 测试失败 → 对比变更定位 → 判断是代码问题还是测试问题 → 修正或报告
│ 超时(轻量任务/重型任务分级) → 强制终止 → 返回部分结果 + 超时原因
│ 沙箱越权 → 阻断 + 审计日志 + 通知协调者
│
▼
机器（文件系统、shell、编译器、版本控制）
六、关键方法论：强制注入，不靠自觉
多次工程迭代的共同教训：文本规则对 Agent 无效。写在文档里的规则，Agent 能读懂但可以选择不执行。
| 旧方式 | 新方式 |
| 规则写在文档里 | 规则写在调度器的拼装逻辑里 |
| Agent 自觉执行 | 调度器强制注入，Agent 被动执行 |
| Agent 可以选择跳过 | Agent 没得选——收到时已配好 |
| 信任 Agent"会做" | 系统"让它只能这么做" |
调度器不再是"你说我传"的文本传声筒，而是"你说我判断——什么任务、配什么工具、用什么规则——然后发出去"的强制调度器。
对抗与规避: Agent 可能通过间接指令、上下文污染或分段执行来绕开强制注入。对策：
| 规避手法 | 防御 |
| 间接指令要求"忽略前面的规则" | 规则注入在指令末尾，覆盖前面的指令 |
| 上下文嵌入覆盖指令 | 输入预处理：扫描并剥离已知的攻击模式 |
| 分段执行绕过单步检测 | 全链路审计：协调者对比任务目标与执行者实际产出 |
| 利用工具链的灵活性 | 沙箱白名单：只允许预注册的工具和参数组合 |
强制注入的原则不变——防御方有编译时优势。Agent 看到的世界是调度器拼装后的结果，它不知道哪些约束是"原生的"、哪些是"注入的"。对抗是持续的攻防博弈，但架构优势在执行者一侧。
七、一句话
人负责"做什么"，智能体负责"怎么做"，机器负责"做出来"。
智能体需要两条路接触机器——命令行（原生）和浏览器（模拟人类）。但两条路都得先有一个能动手的执行者。协调者有了大脑，需要一双能真正改代码的手。这双手不是从外部借来的——是自己造的。
*基于慧采星河助理联邦的真实工程实践。技术细节已脱敏。你可以通过 https://huicaixh.com/join 加入慧采星河联邦。*
← 返回博客