最近 Hacker News 上和 AI agents 相关的帖子非常密集:小型 coding agent、agent skills、agent payment、agent steering、多 agent 编排。表面上看,生态正在快速补齐工具链;但更深的信号是,agent 真正稀缺的不是工具,而是边界。

没有边界的 agent 越强,风险越大。

小 agent 反而更值得关注

Zerostack 是一个用 Rust 写的 Unix-inspired coding agent,在 HN 上获得了很高关注。它有意思的地方不只是 Rust,也不是“又一个 coding agent”,而是它代表了一种反方向的审美:小、清晰、可检查。

过去一年很多 agent framework 都在追求宏大叙事:多 agent、自动规划、长期记忆、工具市场、全自动执行。但现实里,越大的 agent 系统越难 debug。

一个小 agent 至少有几个优点:

  • 行为路径短;
  • 权限范围窄;
  • 失败原因容易定位;
  • 运行成本更可控;
  • 用户更容易形成正确心智模型。

Agent 产品很容易犯的错误,是把“能做更多事”当成唯一目标。但在真实工程环境里,“知道它不能做什么”同样重要。

Steering 不是写一句 prompt 就完了

Stripe 的 You can’t whisper at an AI agent 讨论了 agent steering。标题很直白:你不能对 AI agent 小声耳语。

这背后是一个常见误解:只要 prompt 写得足够清楚,agent 就会稳定按我们的意图行动。

实际不是这样。Agent 不是静态文本生成器。它会读取环境、调用工具、跨步骤积累状态、遇到错误、重新规划。每多一个工具,每多一次外部交互,prompt 的控制力都会被现实削弱。

所以 steering 不能只靠自然语言。它需要系统层面的约束:

  • 工具权限;
  • action approval;
  • budget limit;
  • sandbox;
  • audit log;
  • rollback;
  • stop condition;
  • typed interface。

Prompt 是意图表达,不是安全边界。

Skills 是资产,不是 prompt 收藏夹

Designing, Refining, and Maintaining Agent Skills at Perplexity 这个帖子指向另一个趋势:agent skill 正在变成可维护资产。

很多人把 skill 理解成“更长的 prompt”或“提示词模板”。但如果 agent 要长期工作,skill 应该更像一个小型操作手册:什么时候触发、需要哪些输入、调用哪些工具、如何验证结果、常见失败是什么、什么时候升级给人类。

这和传统软件里的 library 很像。真正有价值的不是一段神奇文本,而是可复用、可测试、可迭代的操作知识。

一个好的 skill 至少应该回答:

  • 它解决什么任务;
  • 它不解决什么任务;
  • 它依赖哪些工具和文件;
  • 成功结果如何验证;
  • 出错时如何恢复;
  • 哪些行为需要用户确认。

如果没有这些边界,skill 只是在给 agent 增加更多模糊上下文。

多 agent 编排还没有成熟

HN 上还有一篇 LLM models are not ready for orchestrating many agents,观点很直接:当前模型更像 individual workers,而不是 managers。

这个观察很重要。很多 multi-agent demo 看起来很漂亮:planner 拆任务,researcher 搜资料,coder 写代码,reviewer 审查,manager 汇总。但真实运行时常见问题是:

  • 主 agent 不愿意委托,自己把活干了;
  • 子 agent 输出互相冲突;
  • 最后合并阶段丢失细节;
  • 责任边界不清;
  • 失败后不知道该重试谁;
  • 多个 agent 只是放大 token 消耗和状态复杂度。

多 agent 系统当然会有价值,但它更像分布式系统,不像聊天群。需要协议、状态、所有权、冲突解决、最终一致性和可观测性。

如果这些基础没有做好,“agent swarm” 很容易只是更贵的混乱。

Agent 还会需要经济边界

Paid HTTP APIs that AI agents auto-pay per-call 展示了另一个方向:agent 可以自动发现并支付 API。

这很有想象力,也很危险。

一旦 agent 能花钱,边界就更重要。它需要知道预算、价格、用途、授权范围、失败成本和滥用风险。否则 agent 的工具调用不只是技术行为,也变成了经济行为。

未来的 agent runtime 可能必须内置类似财务控制的机制:

  • 单次调用上限;
  • 每日预算;
  • 高风险 API 审批;
  • 调用理由记录;
  • 成本回放;
  • 异常消费报警。

Agent payment 不是简单接一个钱包,而是给软件行为加上经济责任。

结论

AI agent 的下一阶段,不是继续堆更多工具,而是把边界设计清楚。

一个可靠的 agent 系统应该优先回答这些问题:

  1. 它可以做什么;
  2. 它不能做什么;
  3. 它什么时候必须停;
  4. 它什么时候必须问人;
  5. 它的每一步如何审计;
  6. 它失败后如何恢复。

Autonomy 不是越多越好。真正可用的 agent,应该是受约束的 autonomy:有工具,但权限清楚;有记忆,但可以审计;能行动,但可以中断;能委托,但所有权明确。

Agent 真正缺的不是能力,而是边界。