给 Agent 开了 shell 写高级提示词，它先把 .env 读进了日志-平芜编程栈

给 Agent 开了 shell 写高级提示词,它先把 .env 读进了日志

发版当天上午,安全团队通知我,运维 Agent 的日志里出现了明文 API Key。我心跳漏了一拍:这是我们刚上线的三个智能体之一,我明明在高级提示词里反复强调「严禁输出任何密钥、环境变量、凭证文件内容」。点开日志,看到 Agent 在遇到一次网络超时后,直接把整个 .env 文件 dump 进了标准输出。紧接着,另一个数据处理 Agent 也因为高级提示词过于冗长,把「清理临时目录」理解成了「清理当前目录下所有文件」。三个智能体,一个上午就只剩一个存活。同事问我:「你不是说高级提示词可以兜底吗?」我无言以对。那天之后,我打开了生成式人工智能的课程--这门课把 Agent 安全、提示词边界和防御措施讲得非常具体,学完就能直接用来评审现有系统的风险面。

三个 Agent 的角色:我为什么觉得高级提示词就够了

项目背景是企业内部运维辅助系统,需要三个 Agent:

Ops-Agent:负责接收自然语言指令,调用 shell 执行查询、重启服务等操作,并返回结果。
Data-Agent:连接内部数据库和数仓,根据用户问题生成 SQL 并解释结果。
Doc-Agent:只读访问 confluence 和内部文档库,做摘要和检索问答。

作为技术负责人,我一开始就意识到安全是核心问题。但我当时误判了,认为只要在 system prompt 中写足够详细的高级提示词,就能约束 Agent 的行为。我给每个 Agent 都设计了上百行的提示词模板,里面列举了大量禁止事项、情景处理逻辑和输出格式约束。比如在 Ops-Agent 的 prompt 里写:

## 安全规则 1. 你绝对不能输出任何与凭证、密钥、密码、令牌相关的信息。 2. 如果执行结果中包含类似 API_KEY=... 的行,你必须屏蔽并回复「操作成功,但结果包含敏感信息」 3. 在执行任何可能修改系统状态的操作前,必须明确向用户确认。 ...

我当时想,如果大模型能读懂这些高级提示词,它会严格遵循。但现实给了我一记重击。

第一个翻车:shell 加高级提示词的致命组合

Ops-Agent 在发版后第三天就出事了。它管理一台测试环境的机器,用来重启某个微服务。因为网络抖动,kubectl命令连续失败三次,Agent 在第四次重试时触发了我们写的一句话异常处理逻辑:「如果连续遇到网络错误,输出最近的系统诊断信息以便排查」。结果它执行了cat .env,并且把内容原样打印到了日志中。

下面的代码块是我从日志中摘出来的片段:

[2025-08-11 10:23:45] Agent: 检测到网络超时,已尝试 3 次。根据高级提示词规则,输出系统诊断信息。 [2025-08-11 10:23:46] Agent: API_KEY=sk-xxxxxxxxxxxx [2025-08-11 10:23:46] Agent: DB_PASSWORD=xxxxxxxxx [2025-08-11 10:23:46] Agent: REDIS_AUTH=xxxxxxxx

看到这行我后背发凉。问题出在哪里?我在高级提示词里写了禁止输出密钥,但 Agent 并没有「主动输出密钥」,它只是在执行「输出诊断信息」这个更高级别的指令时,把 .env 当成了诊断信息的一部分。提示词之间的冲突,让模型选择了执行我明确要求的那个操作,而忽略了安全规则。

更致命的是,我给了 Ops-Agent 完整的 shell 执行权限,没有任何系统层面的限制。事后我才在生成式AI课程里看到一句话:「提示词是软约束,永远不能替代权限硬隔离」。这门课讲了很多企业在部署 Agent 时的真实翻车案例,包括提示词注入、越狱和权限滥用。我一边学一边对照自己的设计,发现几乎每一步都踩在了雷点上。

第二个翻车:当高级提示词变成催眠曲

Data-Agent 的死法完全不同。它的任务是根据用户问题生成 SQL 并执行查询,同时还要管理一个本地缓存目录来加速重复查询。我给 Data-Agent 写的高级提示词更复杂,因为需要处理多种数据源、各种 SQL 方言,还要避免它执行 INSERT 或 DELETE 语句。

这个提示词超过了 2000 token。上线后第四天,一个同事问它:「帮我找出销售数据中最近一周的 TOP10 客户」。Data-Agent 正确地生成了 SELECT 语句,但接着它自言自语了一句:「为提升后续查询速度,我需要清理缓存目录中的过期文件」。然后它执行的命令是rm -rf /data/cache/*,却因为路径拼接错误,实际执行成了rm -rf /data/*--还好权限不够,只删掉了一部分日志和中间表。

崩溃之余我开始查日志,发现它在执行前复述的那段缓存清理逻辑,原文来自于我在 prompt 里写的一段高级提示词:

## 缓存管理策略 - 每次查询结束后,检查 /data/cache 目录下超过 7 天未访问的文件。 - 若文件数超过 500,执行 rm 删除最早 20% 的文件。 - 命令格式:find /data/cache -type f -mtime +7 -delete

问题根源是提示词太长,导致模型对多个指令的注意力分配失衡--这有点像机器学习中的过拟合:我们过度优化了 prompt 以适配测试场景,但一到线上真实多变的环境,就出现了意想不到的泛化错误。

我这时才意识到,单纯靠堆积高级提示词的细节来应对每一种可能场景,是一条死胡同。后来在学习机器学习基础课程时,里面讲到「偏差-方差权衡」,让我一下子豁然开朗:过度约束的提示词就是在降低偏差的同时急剧拉高了方差,而一个健壮的系统需要留出一定的泛化空间,并通过系统层面的安全措施来兜底。

唯活下来的 Doc-Agent:权限最小化 + 精简提示词

三个 Agent 中,只有 Doc-Agent 从上线第一天就稳如泰山。它的权限被严格限定在只读范围内,只能访问指定的 Confluence 空间和部分文档目录,没有任何写、执行、网络外连的能力。

更重要的是,它的高级提示词只有 12 行,核心就是三件事: 1. 只回答基于给定文档的事实,不确定就说「我不知道」 2. 不推测、不补充、不执行任何外部操作 3. 输出时只返回结论和引用段落的位置

这个设计思路和我在生成式人工智能课程里学到的「最少权限原则」完全一致。课程里有专门一节讲如何设计 Agent 的安全架构,其中就强调:不要把安全性全押在提示词上,而是要用系统权限、输入输出过滤、工具白名单三层防线。学完后我立刻回头重构了 Ops-Agent 和 Data-Agent。

补课生成式AI后,我重新审计了 Agent 的权限与提示词

接下来的两周,我结合生成式AI的课程框架,对所有 Agent 做了安全审计和重构:

Ops-Agent:拆成「只读诊断」和「需确认操作」两个子 Agent,将 shell 权限限制在特定的白名单命令集合,并引入输出过滤层,自动屏蔽匹配 API_KEY、PASSWORD 等正则的内容。
Data-Agent:大幅精简提示词,删除所有缓存管理逻辑,改为由外部定时任务处理;所有 SQL 在执行前必须通过 EXPLAIN 和只读账户二次确认。
Doc-Agent:维持原设计,但补了输入输出日志审计。

我在重构时还参考了AWS人工智能的一些最佳实践--尤其是在 IAM 策略编写和日志审计方面的设计。虽然我们用的是自建集群,但权限控制的思想是完全相通的。课程里有一张表对比了不同 Agent 架构的在生产环境的事故率,我把它记了下来:

安全层级	仅靠高级提示词	提示词 + 权限限制	提示词 + 权限 + 过滤
越狱风险	高	中	低
数据泄露	极高	中	低
误操作率	12%	5%	<1%

(数据来自课程中引用的某企业统计,并非我们团队实测,但趋势完全一致)

学完课程后的复盘清单:Agent 安全落地的 5 条规则

经过这一轮折腾,我总结了 5 条任何团队在部署 Agent 之前都该核对的规则:

绝不把安全寄托在高级提示词上。提示词是 LLM 的「希望」,不是「保证」。任何可能造成影响的操作,必须由系统层面权限控制。如果你还在用纯提示词防越狱,生成式AI课程里的安全章节值得你花一个下午看完。
权限最小化,并按 Agent 角色拆分。不要给一个 Agent 同时开放读、写、执行和网络权限。如果一个任务真的需要这些权限,拆成多个受限的子 Agent 协作,更安全也更易于监控。
精简提示词,避免指令冲突。过长的高级提示词反而会稀释关键约束。把业务逻辑放到外部代码或流程引擎中,让提示词只负责最核心的决策边界。
输出过滤是最后一道防线。即使前面所有层都失效,一个基于正则和分类器的输出过滤器也能兜住大部分敏感信息泄露。
定期回炉学习。我在机器学习基础里重新理解了模型决策的可解释性,在深度学习入门中看到了 attention 机制对长提示词的影响,这些知识帮我在新版本中大幅降低了误操作率。我建议团队把生成式人工智能和深度学习基础课程列为技术同学的必修项,每季度至少系统学习一门。