当前位置：首页 > news >正文

为什么我的Agent上线就崩？权限日志比调API更重要

news 2026/8/3 11:47:34

《AI大模型就业为什么越规划越焦虑？问题可能不在路线》看起来是个大话题，但真落到项目里，常常就是几个具体选择。下面我尽量按实际开发时会遇到的问题来讲。

摘要

很多人以为大模型就业就是会调API、会写Prompt就能搞定，但真实企业环境里，一个Demo跑通的Agent上线时，最先崩的往往不是模型推理，而是权限混乱和日志缺失。本文从一个真实的踩坑经历出发，拆解权限控制、日志追踪和可观测性为什么是大模型工程师真正的硬门槛，并给出具体的技能学习顺序和求职建议。

一、一次上线翻车的真实复盘

去年我带团队做了一个内部的知识库Agent，主要功能是让业务同学通过自然语言查询历史文档、获取分析结论。Demo阶段跑得很顺，模型回答质量也不错，当时觉得这项目可以拿去面试展示。

结果一上线，问题全来了。

第一个问题是权限。Agent接入了公司内部文档系统，理论上应该只允许查询当前用户有权限访问的文档。但Demo阶段的代码是这么写的：

# 错误的写法：先获取所有文档，再过滤 def search_documents(query: str, user_id: str): all_docs = vector_db.search(query, top_k=20) # 后期才做权限过滤 filtered = [doc for doc in all_docs if has_permission(doc, user_id)] return filtered

这个逻辑在Demo里没问题，因为测试数据少。但生产环境里，向量库返回的20条结果可能包含用户无权访问的敏感文档。更致命的是，过滤发生在检索之后，模型已经看到了这些文档内容，虽然最终返回给用户时被过滤掉了，但推理过程已经泄露了权限信息。

第二个问题是日志。Agent在查询时调用了多个模型接口，每次调用都有延迟和成本。但系统里没有记录每次调用的输入输出、耗时、Token消耗。当业务方反馈"某个查询特别慢"时，我们完全不知道是模型响应慢、检索慢，还是网络问题。

第三个问题是可观测性。Agent是一个多步骤的Agent，包含检索、推理、格式化几个阶段。但系统没有追踪每个阶段的执行情况，问题定位只能靠猜。有一次模型返回了错误答案，我们排查了两天，最后发现是Prompt里某个条件判断写反了，但因为没有阶段级别的日志，完全找不到问题所在。

这次翻车让我意识到，Demo能跑通和能上线之间，隔着一道巨大的工程鸿沟。

二、为什么权限和日志成了新门槛

这不是我第一次看到这种现象。2024年到2026年，大模型应用经历了明显的阶段迁移：

第一阶段是"模型能力探索期"，大家关注的是模型能做什么，Prompt怎么写效果更好。这个阶段的需求很直接，会调API、会写Prompt就能干活。

第二阶段是"应用落地期"，企业开始把Demo变成正式产品。这时候问题就来了：模型调用要有成本控制，用户查询要有权限限制，系统问题要有日志可查，复杂流程要有可观测性。

第三阶段就是现在，"工程化成熟期"，企业真正需要的是能把Agent稳定运行在生产环境的工程师。

为什么权限和日志成了新门槛？因为大模型应用的错误成本和传统应用不同。

传统应用出bug，最多是数据错误或界面显示问题。但大模型应用出bug，可能是：

权限漏洞导致敏感信息泄露
Prompt注入导致系统被滥用
模型幻觉导致错误决策被自动化执行
成本失控导致账单爆炸

这些问题的排查和预防，都需要权限控制和日志追踪能力。而这是传统程序员教育里很少涉及的。

三、大模型岗位的真实变化

我面试过不少转大模型的程序员，也看过很多简历。发现一个现象：很多人把"大模型工程师"理解成了"会调API的人"。

但真实岗位需求是这样的：

初级大模型工程师：能把Demo变成能稳定运行的服务，处理权限、日志、错误恢复。

中级大模型工程师：能设计Agent架构，处理复杂流程，优化成本和延迟，建立可观测体系。

高级大模型工程师：能把大模型能力集成到现有系统，设计权限模型，建立安全规范，带领团队完成工程化落地。

注意，这三个级别里，"会调API"只是入门要求。真正拉开差距的是工程能力。

我之前面试过一个候选人，简历上写着"精通LangChain，做过多个Agent项目"。聊下来发现，他所有项目都是单机Demo，没有处理过权限问题，没有设计过日志系统，没有考虑过高并发下的成本问题。这样的项目，在面试里能加分，但在实际工作里帮不上忙。

反过来，我见过一个候选人，简历上项目不多，但每个项目都详细描述了权限设计、日志方案、可观测性建设。聊起来逻辑清晰，能说出每个决策的权衡。这种人反而是企业更想要的。

四、必备技能栈：从Demo思维到工程思维

如果要转大模型方向，除了基础的Python和模型调用能力，还需要补齐这些工程能力：

权限控制

这是最容易被忽视的部分。大模型应用涉及的用户数据、文档权限、API密钥管理，都需要精心设计。

推荐的技能点：

RBAC（基于角色的访问控制）在Agent场景的应用
多租户权限隔离的设计模式
API密钥的安全管理（不要硬编码，要用密钥管理服务）
Prompt注入的防御策略

日志系统

日志不是简单打印日志，而是要建立完整的追踪体系。

推荐的技术栈：

OpenTelemetry：标准化的可观测性框架
结构化日志：用JSON格式记录，方便后续分析
分布式追踪：一个请求可能经过多个服务，要能追踪完整链路
日志分级：DEBUG、INFO、WARN、ERROR要有明确的使用场景

# 正确的日志写法示例 import logging import uuid from opentelemetry import trace logger = logging.getLogger(__name__) tracer = trace.get_tracer(__name__) def process_query(user_id: str, query: str) -> dict: # 生成唯一请求ID，贯穿整个调用链 request_id = str(uuid.uuid4()) with tracer.start_as_current_span("agent.process_query") as span: span.set_attribute("user.id", user_id) span.set_attribute("request.id", request_id) logger.info( "开始处理查询", extra={ "request_id": request_id, "user_id": user_id, "query_length": len(query) } ) try: # 权限检查 check_permission(user_id, query) # 检索文档 docs = search_documents(query) # 调用模型 result = call_model(query, docs) logger.info( "查询处理完成", extra={"request_id": request_id, "doc_count": len(docs)} ) return result except PermissionError as e: logger.warning( "权限检查失败", extra={"request_id": request_id, "error": str(e)} ) raise except Exception as e: logger.error( "查询处理异常", extra={"request_id": request_id, "error": str(e)}, exc_info=True ) raise

可观测性

可观测性不只是日志，还包括指标、追踪、告警。

指标：Token消耗、响应延迟、错误率、并发数
追踪：一个请求经过的完整链路
告警：关键指标异常时及时通知

成本优化

大模型调用成本不低，需要建立成本意识。

缓存重复查询结果
合理选择模型（简单任务用便宜模型）
控制Token使用量
设置成本上限和告警

五、项目作品集怎么写才值钱

很多人做项目是为了展示技术能力，但简历上的项目描述往往只写了"做了什么"，没写"解决了什么问题"。

企业更想看的是：

1. 问题定义：你遇到了什么工程挑战？
2. 方案设计：你为什么选择这个方案？有什么权衡？
3. 实施细节：具体怎么做的？遇到了什么问题？
4. 效果验证：怎么证明方案有效？

举个例子，同样是做Agent项目：

差的描述：
> 使用LangChain开发了文档查询Agent，支持自然语言查询，调用GPT-4模型。

好的描述：
> 设计并实现了一个支持多租户的文档查询Agent。核心挑战是权限隔离和可观测性。权限方面，采用RBAC模型，在检索阶段就过滤无权访问的文档，避免信息泄露。可观测性方面，接入OpenTelemetry，为每个请求生成唯一追踪ID，记录完整的调用链路。项目上线后，权限事故率为零，平均响应时间从2.3秒优化到0.8秒。

注意，好的描述里有具体的技术选型、问题解决思路、量化指标。这些才是企业想看的。