一个Agent跑通容易，团队上线才痛苦：权限日志才是真正门槛

聊《程序员职业规划为什么越规划越焦虑问题可能不在路线》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要大模型应用从Demo到生产最大的坑不是模型选错、Prompt写不好而是权限管理和日志可观测性。这篇文章从一个真实项目翻车现场出发拆解程序员在大模型时代的职业重新定位——不是追新模型而是补工程化短板。---目录岗位真相大模型工程师缺的不是调API的人能力分层谁在抢谁的地盘短期先搞定的三件事中期项目沉淀比 Demo 重要长期不可替代的是什么总结---岗位真相大模型工程师缺的不是调API的人去年我带过一个团队招了三个大模型工程师。面试时个个都能跑通 LangChain 的 ReAct Agent写 Prompt 也头头是道。三个月后项目上线第一天就崩了。不是模型回答错了是三个用户同时触发了同一个工具调用权限校验没做日志没接排查了四个小时才定位到问题——一个内部 API 被越权调用数据泄露到了不该看到的部门。这件事让我意识到大模型岗位的竞争格局已经变了。现在市场上最不缺的是会调 API 的人。GitHub 上一搜 Agent 模板Star 几千的比比皆是。真正稀缺的是能把 Demo 变成可维护、可观测、可追责的生产系统的人。岗位趋势的真相初级岗调 API、写 Prompt正在快速贬值AI 自己就能做中级岗工作流编排、工具集成开始内卷门槛在提高高级岗权限设计、日志体系、可观测性严重稀缺但大多数人不知道这个方向我观察了几十个大模型项目的招聘要求发现一个规律凡是要求有生产环境部署经验的岗位薪资比纯算法岗还高。 这不是因为算法难是因为真的没人做过。---能力分层谁在抢谁的地盘我把大模型相关岗位的能力分成四层越往下越值钱第一层模型调用者会调 API会用 LangChain/LlamaIndex能写 Prompt。这是目前最卷的层次培训班三个月就能达到。第二层工作流工程师懂 LangGraph、懂 Agent 编排、能把多步骤任务拆成可执行的流程。这一层开始有门槛但很多高级工程师其实也只做得到 Demo 级别。第三层工程化工程师懂权限设计、懂日志规范、懂可观测性、懂生产环境的坑。这一层的人往往是传统后端转过来的或者自己踩过足够多的坑。第四层架构决策者知道什么时候该用 Agent、什么时候不该用知道模型的边界在哪里知道团队的技术债该在哪里控制。这一层不是学出来的是项目堆出来的。我的判断大多数人应该把目标定在第三层而不是第一层。第一层正在被 AI 替代——Claude Code、Cursor 这些工具已经能完成大部分调 API 写 Prompt的工作。但权限设计、日志体系这些东西AI 暂时还帮不了你。---短期先搞定的三件事如果你现在想转型大模型我建议你按这个顺序来不要一上来就追新模型。第一件事把权限模型补上很多 Agent 项目翻车根源是权限没设计好。一个典型的场景用户 A 通过 Agent 查询了用户 B 的数据因为 Agent 没有做权限隔离直接调用了后端 API而那个 API 没有校验当前用户身份。正确的做法# 错误的做法Agent 直接调用 API没有权限校验 async def agent_call_api(user_input): result await backend_api.query(user_input) return result # 正确的做法权限校验前置 async def agent_with_permission_check(user_id, user_input): # 1. 校验当前用户是否有权限执行此操作 if not await check_permission(user_id, user_input): raise PermissionError(无权访问) # 2. 注入用户身份到上下文 context { user_id: user_id, input: user_input, permission_scope: await get_user_scope(user_id) } # 3. Agent 在权限范围内执行 result await agent.execute(context) return result学习建议 不要只看大模型相关的教程去补 OAuth2、RBAC、ABAC 这些传统权限模型的知识。这些在大模型时代反而更关键了。第二件事建立日志规范日志不是加个 print 就叫日志了。生产环境的日志需要解决三个问题谁在什么时候做了什么、为什么这么做、结果如何。一个基础的 Agent 日志结构import logging import uuid from datetime import datetime # 结构化日志配置 logging.basicConfig( format%(asctime)s | %(levelname)s | %(message)s, datefmt%Y-%m-%d %H:%M:%S ) logger logging.getLogger(agent) async def logged_agent_call(user_id: str, request: dict) - dict: trace_id str(uuid.uuid4()) start_time datetime.now() logger.info(f[TRACE:{trace_id}] User:{user_id} | Start | Request:{request}) try: result await agent.execute(request, trace_idtrace_id) elapsed (datetime.now() - start_time).total_seconds() logger.info( f[TRACE:{trace_id}] User:{user_id} | Success | fElapsed:{elapsed}s | Tokens:{result.get(tokens)} ) return result except Exception as e: elapsed (datetime.now() - start_time).total_seconds() logger.error( f[TRACE:{trace_id}] User:{user_id} | Failed | fElapsed:{elapsed}s | Error:{str(e)} ) raise关键点 每个请求要有 trace_id贯穿整个调用链。这样出问题的时候才能从日志里还原完整路径。第三件事学会写交付文档这不是套话。很多项目上线后没人敢维护不是因为代码烂是因为只有写代码的人知道系统在干什么。交付文档至少包含系统架构图谁调了谁权限模型说明谁能做什么日志查询指南出问题怎么查已知限制和坑别让用户踩---中期项目沉淀比 Demo 重要简历上写做过三个 Agent 项目不如写把一个 Agent 从 Demo 推到生产处理了权限、日志、可观测性三个问题。我的建议做一个完整的、能上线的项目而不是五个 Demo。一个能体现工程化能力的项目应该包含1. 完整的权限设计用户身份验证、操作权限控制、数据隔离2. 结构化的日志体系trace_id 贯穿、关键节点记录、异常告警3. 可观测性延迟监控、Token 消耗、错误率4. 文档和交接其他人能看懂、能维护项目展示技巧不要只放 GitHub 链接。在简历或面试里用 STAR 法则讲清楚S情境项目是什么为什么需要做T任务你负责什么难点在哪A行动你怎么解决的用了什么方案R结果上线后效果如何有什么数据举个例子 我负责一个内部知识库 AgentDemo 阶段回答准确率 85%。但上线后发现两个问题一是权限没隔离不同部门的员工能看到对方的文档二是日志缺失出问题无法排查。我重新设计了基于 RBAC 的权限层接入了结构化日志和 trace_id 追踪。上线后权限事故为零平均排查时间从 4 小时降到 15 分钟。这种描述比我用 LangChain 做了个 Agent有价值得多。---长期不可替代的是什么很多人担心 AI 会取代程序员。这个担心有道理但方向搞错了。AI 取代的是重复性劳动不是判断力。一个大模型工程师不可替代的能力是在约束条件下做权衡这个场景该用 Agent 还是用传统 API权限粒度要做到什么程度日志要记到什么级别成本多少这个功能上线后出了问题谁负责这些判断AI 给不了你答案。它只能给你选项决策权在你。长期竞争力的核心工程化思维 业务理解。工程化思维让你知道系统的边界在哪里业务理解让你知道什么时候该妥协、什么时候该坚持。我见过太多人技术栈换了一个又一个但从没真正解决过一个生产环境的问题。这种人换多少模型都一样焦虑。---总结大模型时代的职业规划不是追新模型、学新框架。真正的机会在Demo 到生产的最后一公里。权限设计、日志体系、可观测性——这些传统后端工程师的看家本领在大模型时代反而更值钱了。因为 AI 能帮你写代码但帮不了你决定这段代码该怎么安全地上线。我的建议1. 别只学大模型把传统工程化知识补上2. 做一个能上线的项目而不是五个 Demo3. 学会写文档、做交接这是高级工程师的门槛4. 培养判断力知道什么时候该用什么方案焦虑的本质是不知道自己缺什么。搞清楚Demo 和生产的差距你就知道该往哪走了。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。