夜雨聆风这件事本身不大，就是把“经验文章”的列表做得更好用一点。但改完之后，我反而更明显地感受到：做 AI Agent 时，最容易出问题的，可能不是它能不能调用工具，而是我有没有先把边界说清楚。
一、问题是什么
今天的真实触发点是文章列表页面。
后面每天都会生成一篇 AI 使用经验文章，如果所有文章一直平铺在左侧列表里，刚开始两三篇还好，等文章多了之后，大概率就会变成一长串，很难找，也很难知道哪篇是哪天生成的。
所以我今天给 AI 的要求很具体：文章按日期周期收起来，周期上显示文章数量，最新的在最上面，每篇文章卡片上也要显示生成日期。
这个需求看起来很简单，但真拆开后会发现，它至少包含几件小事：按月还是按周分组，默认展开哪个周期，历史周期要不要收起，选中文章时怎么保持高亮，搜索时日期要不要参与匹配。
如果我只说一句“帮我优化文章列表”，AI 很可能会自己发挥。它可能会加筛选器，可能会重做样式，也可能顺手调整其它页面。看起来都像是在帮忙，但未必是我今天真正需要的。
二、为什么会发生
这让我想到 AI Agent 和普通对话的一个差别。
普通对话里，AI 多想一步，有时候是好事。它多给一个方案，多提醒一个风险，我可以当场判断要不要采纳。
但 Agent 一旦开始执行，就不只是“多想一步”了。它可能会连续读文件、改代码、跑脚本、生成结果。这个时候，如果边界不清楚，它就会把“可能有帮助”当成“可以继续做”。
今天这个页面优化就是一个小提醒。我真正需要的是“列表能折叠、日期能看见、最新内容靠前”，不是重新做一套文章管理系统。
这也是我觉得做 Agent 前必须先想清楚的地方：
这次只解决什么问题？ 它可以动哪些文件？ 哪些动作需要先停下来确认？ 做到什么程度就算完成？
三、可以怎么做
现在看来，我更愿意把 Agent 当成一个“有边界的执行者”，而不是一个什么都能自由发挥的助手。
今天这次改动，我给 AI 的边界其实就比较清楚：先看当前文章列表和数据字段，再只改文章列表渲染逻辑；按月分组，默认最新月份展开；验证脚本语法和前端数据生成；不要动无关页面。
这样一来，AI 执行时就更像一个可复核的 Agent。它知道该读哪些文件，知道要改哪里，也知道改完后要用什么方式验证。
其实这和任务拆解很像。一个看起来有点模糊的目标，如果能拆到足够小，拆到每一步都能被判断，它就没有那么难了。Agent 也是一样。边界越清楚，它越不容易跑偏。
我今天最大的感受是：不要只告诉 AI “做什么”，还要告诉它“做到哪里就停”。
四、一个简单判断方法
下次再准备让 AI 自动执行前，我会先问自己这几个问题：
一句话总结就是：
Agent 不是会调用工具就够了，还要知道什么时候不能继续。如果这里面有两项答不上来，我就不会急着把它做成自动化 Agent。可以先让 AI 以助手方式跑一两次，把步骤、误判和确认点暴露出来。等这个过程稳定了，再沉淀成工作流，最后才考虑变成 Skill。
五、哪些情况不适用
当然，也不是所有任务都适合 Agent 化。
如果只是一次性查询、简单整理、临时改一个文件，用普通 AI 对话就够了。强行做成 Agent，反而会增加配置和复核成本。
真正适合 Agent 的，是那些会重复出现、步骤相对稳定、工具链明确、风险边界也能写清楚的任务。比如每天固定生成文章、跑复盘、更新数据，这类事情就更适合一点点沉淀下来。
六、总结
今天这个小页面改动，让我对 Agent 的边界又多了一点体感。
以前我可能会更关注它能不能调用工具，能不能自己完成更多动作。现在看来，工具当然重要，但更重要的是，它知道哪些事可以做，哪些事不能做，做到哪里应该停下来。
下次再做 Agent，我会先补一张边界清单，再让它接工具。
这不是削弱它的能力，而是让它的能力更可靠。毕竟，一个不知道停在哪里的 Agent，跑得越快，反而越让人不放心。
