【构建AI Agent的九条实战法则：Unix哲学的回归】

Philipp Schmid分享了一份构建Agent的实战清单，每一条都直指开发中最容易踩的坑。

一、回归Unix基础

文件系统和命令行是Agent的最佳工作台。所有工具和子Agent应该共享同一个文件系统，让它们能够读写彼此的工作成果。这听起来简单，却是很多Agent架构悄然崩塌的地方——如果每个工具都在自己的小沙盒里写数据，你最终会得到“幽灵状态”，Agent开始幻想自己取得了进展。

有开发者的做法值得借鉴：强制建立简单的工作区契约，使用可预测的路径、只追加的日志、以及一个Agent必须更新的“唯一真相源”。

二、代码生成不只是写代码

用代码生成来处理非编码任务，比如数据分析或工具调用链。这个思路打开了新的可能性。

三、验证是生命线

让Agent在完成任务前运行脚本或检查错误。没有验证的Agent就像没有刹车的汽车。

四、子Agent的边界艺术

用子Agent处理特定任务，只返回最终答案给主Agent。这避免了主Agent被中间过程搞糊涂。好的Agent本质上是纪律严明的系统：共享文件系统、小型工具、代码驱动的验证、清晰的子Agent边界。

五、别把大象塞进上下文

避免把巨大文件加载到上下文中。写脚本或命令来搜索和提取需要的特定数据。有人在子Agent间尝试“工作记忆摘要”而非完整对话历史，token使用量降低了60%，质量损失却很小。

六、Trace是你的显微镜

阅读Agent的执行轨迹，理解它究竟为什么、在哪里犯了错。当调用链变长时，这是定位真相源头的唯一方式。

七、精确查询胜过语义搜索

对于结构化数据，查询往往比语义搜索更可靠。有开发者反馈，放弃向量数据库、直接给AI原始数据后，效果反而更好。共享文件系统是最原始的共享内存，别用向量数据库把简单问题复杂化。

八、让Agent学会读错误信息

设计你的Agent来处理错误，让它能够阅读错误消息并据此行动。

九、来自实战的补充

社区开发者补充了几条血泪经验：记录每一步并带时间戳；对长时间运行的任务设置超时终止；对中间文件做版本控制；能用确定性工具就别用LLM调用。这些能省下数周的调试痛苦。

对于面向公众的Agent，还要假设prompt会被滥用，为每个工具设置恰当的权限描述，严格测试，并建立快速响应的反馈循环。

有人调侃：“第一条就劝退了50%的vibe coder。”但这恰恰说明了问题所在——AI编程对脚本能力要求很高，你需要对计算机系统和交互命令有深入了解才能游刃有余。

一句话总结：别再提示Agent了，开始架构它们。

x.com/_philschmid/status/2010339409720160684