前言

过去的软件开发中，开发者最害怕什么？

可能是：

• 空指针异常；
• 数据库故障；
• 线上服务崩溃；
• 用户输入导致程序错误。

因为这些问题虽然麻烦，但有一个共同特点：

它们的行为是确定的。

代码怎么写，程序就怎么执行。

但是 AI Agent 出现后，软件系统迎来了一个新的挑战：

程序开始“自己做决定”。

一个拥有工具调用能力的 Agent，可以：

• 查询数据库；
• 修改文件；
• 调用企业 API；
• 操作浏览器；
• 执行业务流程。

它不再只是输出文字，而是在真实世界中执行动作。

这带来了一个新的问题：

如果 AI 做错了，我们知道它为什么错吗？

如果答案是否定的，那么给 Agent 越多权限，风险反而越大。

---

一、AI Agent最大的风险，不是不会做事，而是会“错误地做事”

很多开发者第一次体验 Agent 时，会觉得：

“它终于像一个真正的智能助手了。”

例如：

用户：

帮我整理一下项目中的无用文件。

Agent：

1. 查看目录结构；
2. 分析文件用途；
3. 判断哪些文件可以删除；
4. 调用删除工具。

整个流程非常自然。

但是问题在于：

第四步是真实操作。

如果 Agent 判断错误：

可能删除：

• 配置文件；
• 数据库文件；
• 用户上传资料。

传统程序不会这样。

因为传统程序通常：

用户输入

↓

固定逻辑

↓

执行结果

而 Agent：

用户目标

↓

模型理解

↓

自主规划

↓

选择工具

↓

执行操作

中间多了一层：

“决策”。

而决策本身存在不确定性。

---

二、Fedora目录删除事件暴露了什么问题？

类似事件最大的警示并不是：

“AI不能拥有权限。”

而是：

AI拥有权限时，必须拥有完整的控制和审计能力。

很多团队开发 Agent 时，关注重点通常是：

• 模型够不够强；
• Prompt写得好不好；
• Tool数量够不够多。

但是容易忽略：

Agent执行之后怎么办？

例如：

Agent调用：

delete_file()

系统应该知道：

• 谁触发的？
• 为什么调用？
• 删除了什么？
• 删除前模型判断了什么？
• 是否经过确认？

如果这些信息都不存在。

那么出现问题后：

开发者只能重新猜。

---

三、传统日志为什么无法保护AI Agent？

很多团队会给 Agent 加日志：

logger.info(result)

记录最终结果。

例如：

用户请求：

整理项目文件


结果：

执行完成

看起来没问题。

但是关键问题：

Agent为什么执行这些操作？

日志没有记录。

真正需要的是：

完整决策链。

例如：

Trace:

用户:

整理项目文件


↓

Agent:

分析目标


↓

LLM:

认为cache目录可以删除


↓

Tool:

调用delete_file


↓

结果:

删除成功

如果出现问题：

马上可以定位：

错误发生在：

• 用户需求理解；
• 模型规划；
• 工具选择；
• 参数生成。

---

四、给Agent增加“行车记录仪”：Observability

如果说：

服务器需要监控。

浏览器需要DevTools。

那么：

AI Agent需要可观测系统。

它需要记录：

1. 思考路径（Reasoning Trace）

不是保存模型内部隐私推理，而是记录：

Agent执行过程中的关键步骤。

例如：

Task:

生成销售分析


Step1:

获取销售数据


Step2:

调用统计工具


Step3:

生成报告

开发者可以理解：

Agent完成任务的大致路径。

---

2. 工具调用记录

例如：

Agent调用数据库：

{
"tool":"query_database",
"params":{
"table":"orders"
},
"status":"success"
}

如果发生异常：

可以快速定位。

---

3. 权限行为记录

尤其是：

文件操作。

数据库修改。

企业系统调用。

必须知道：

Agent做过什么。

---

五、Langfuse：让Agent行为透明化

目前很多团队使用 Langfuse 解决 LLM 应用监控问题。

它类似：

后端领域的链路追踪工具。

整体流程：

              用户

                |

              Agent

                |

       -----------------

       LLM

       RAG

       Tools

       MCP

       -----------------

                |

             Langfuse

                |

           可视化分析

它可以记录：

• Prompt版本；
• 模型调用；
• Token消耗；
• 工具执行；
• 响应时间；
• 错误信息。

当 Agent 出问题：

开发者可以直接查看完整执行链。

---

六、Opik：帮助Agent持续优化

除了监控，另一个重要问题是：

如何让 Agent 越来越好？

这需要：

评估。

例如：

同一个客服Agent。

Prompt版本A：

用户满意度：

82%。

Prompt版本B：

用户满意度：

91%。

如果没有评估系统，只能靠人工感觉。

Opik等工具可以帮助团队：

• 自动测试Agent；
• 对比不同Prompt；
• 分析失败案例；
• 优化工作流。

---

七、企业部署Agent必须增加哪些安全机制？

一个真正生产级 Agent，不应该直接拥有无限权限。

推荐架构：

用户

↓

Agent

↓

权限控制层

↓

MCP Server

↓

真实资源

例如：

删除文件：

不是：

Agent → delete()

而应该：

Agent

↓

申请删除

↓

权限检查

↓

人工确认

↓

执行删除

尤其涉及：

• 财务；
• 用户数据；
• 生产数据库；
• 文件系统；

必须增加保护机制。

---

八、未来AI安全的核心：从限制AI，到管理AI

很多人认为：

AI安全就是：

“不让AI做危险事情。”

但未来更重要的是：

让AI可以做事情，同时保持：

可追踪。

可解释。

可恢复。

可审计。

就像企业管理员工：

不是禁止员工工作。

而是：

• 分配权限；
• 记录操作；
• 评估表现。

Agent也一样。

---

九、没有可观测性的Agent，就是生产环境里的未知风险

现在很多AI项目的问题：

不是模型能力不足。

而是工程体系不足。

开发者花大量时间：

优化Prompt。

调整模型。

增加工具。

但是忽略：

如何发现错误。

如何复盘错误。

如何避免错误重复发生。

未来企业级Agent一定需要：

LLM

+

RAG

+

MCP

+

权限控制

+

Observability

+

Evaluation

模型负责智能。

工程负责可靠。

---

总结

AI Agent最大的变化，是它开始从“回答问题”走向“执行任务”。

而执行任务意味着：

它会影响真实系统。

当一个Agent可以：

修改文件；

操作数据库；

调用企业服务；

它就必须像生产系统一样被监控。

没有可观测性的Agent，就像：

没有日志的服务器。

没有黑匣子的飞机。

出了问题，只能等待事故发生后猜原因。

未来AI应用竞争，不只是模型能力竞争，更是工程能力竞争。

谁能够让Agent：

更聪明；

更稳定；

更安全；

更可控；

谁才能真正把AI从Demo带入生产环境。