Agent能跑通Demo，为什么上线就崩？普通程序员该补的可能是权限和日志-尧图网络科技

聊《AI大模型就业为什么越规划越焦虑？问题可能不在路线》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

摘要：大模型应用从 Demo 转向权限、日志和可观测，企业真正需要的不是会调 API 的人，而是能把 Agent 稳定交付到生产环境的人。这篇文章结合一次真实需求评审，拆解普通程序员转型大模型方向的技能缺口和实战路径。

---

1. 从 Demo 到生产：大模型应用正在发生什么变化
2. 岗位变了：企业真正需要什么样的大模型工程师
3. 必备技能栈：权限、日志、可观测才是硬通货
4. 项目作品集：怎么展示才能过简历筛选
5. 求职路线：普通程序员怎么转型
6. 总结

---

从 Demo 到生产：大模型应用正在发生什么变化

上周参加了一个需求评审，团队要做一个内部知识库问答 Agent。产品经理问："这个 Agent 能查所有文档吗？" 我反问："谁能查？查完能做什么？" 产品经理愣了一下，说："应该所有人都能查吧。"

这个对话让我意识到，很多人做 Agent 还停留在 Demo 阶段——能跑通就行，不考虑权限、日志、可观测。但企业上线时，这些问题会直接导致项目崩盘。

行业趋势正在从"能跑通"转向"能稳定交付"。

我看到很多初级工程师简历上写着"做过 LangChain Agent"，但真正问起来，连权限怎么隔离、日志怎么采集、异常怎么兜底都说不清楚。企业不敢把 Agent 上线，不是因为技术不够炫，而是因为没人敢保证它不会乱调用接口、不会泄露敏感信息、出了问题找不到原因。

关键变化有三点：

权限隔离：Agent 调用工具时，需要知道"谁能做什么"，而不是"能做什么"
日志可追溯：每次调用的输入、输出、耗时、错误原因，都要能回溯
可观测性：线上 Agent 的行为能不能监控、能不能告警、能不能回滚

这三个维度，是 Demo 和生产的分水岭。

---

岗位变了：企业真正需要什么样的大模型工程师

大模型岗位正在分化。

初级岗位：会调 API、会用 LangChain 搭 Demo 的人，供大于求。

中级岗位：能把 Agent 从 Demo 升级到生产级，懂得权限管理、日志采集、异常处理，这类人相对稀缺。

高级岗位：能设计 Agent 架构、制定团队规范、解决复杂场景下的稳定性问题，这类人更是凤毛麟角。

判断标准很简单：

你能不能说清楚一个 Agent 上线前需要哪些非功能需求？
你有没有处理过 Agent 线上故障？
你能不能给团队制定 Agent 开发的规范？

如果答案都是"否"，那你可能还停留在 Demo 阶段。

---

必备技能栈：权限、日志、可观测才是硬通货

普通程序员转型大模型，最需要补的不是算法，而是工程化能力。

权限管理：Agent 调用工具时，需要知道"谁能做什么"。比如知识库 Agent，不同部门的人能查的文档范围不同，Agent 需要根据用户身份动态过滤权限。

# 权限隔离示例：根据用户角色过滤可访问的文档 async def query_knowledge(user: User, question: str) -> str: # 1. 获取用户可访问的文档范围 allowed_docs = await get_user_accessible_docs(user.role, user.dept) # 2. 检索时只检索允许的文档 retrieved = await vector_search(question, allowed_docs) # 3. 构建上下文时注入权限信息 context = build_context(retrieved, user=user) # 4. 调用模型生成回答 response = await llm.generate(context) return response

日志采集：Agent 的每次调用都要记录输入、输出、耗时、工具调用链。出了问题才能回溯。

# 日志采集示例：记录 Agent 调用链 import logging from datetime import datetime logger = logging.getLogger("agent") async def agent_with_logging(user_input: str, tools: list) -> dict: start_time = datetime.now() call_id = generate_call_id() try: # 记录输入 logger.info(f"[{call_id}] Input: {user_input}") # 执行 Agent 逻辑 result = await execute_agent(user_input, tools) # 记录输出和耗时 elapsed = (datetime.now() - start_time).total_seconds() logger.info(f"[{call_id}] Output: {result}, Elapsed: {elapsed}s") return {"status": "success", "call_id": call_id, "result": result} except Exception as e: # 记录错误 logger.error(f"[{call_id}] Error: {str(e)}") return {"status": "error", "call_id": call_id, "error": str(e)}

可观测性：线上 Agent 的行为能不能监控、能不能告警、能不能回滚。这需要和现有监控系统（如 Prometheus、Grafana）集成。

学习顺序建议：

1. 先理解 Agent 的基本架构（感知-思考-行动）
2. 再学习权限管理（RBAC、ABAC）
3. 然后学习日志采集和可观测性
4. 最后学习异常处理和兜底策略

---

项目作品集：怎么展示才能过简历筛选

很多工程师的项目经历写得像 Demo 说明书："基于 LangChain 实现了知识库问答 Agent"。这种写法过不了简历筛选。

好的项目描述应该包含：

背景：为什么做这个 Agent？解决了什么问题？
边界：Agent 的权限范围是什么？不能做什么？
取舍：为什么选择这个方案？放弃了什么？
验收标准：怎么判断 Agent 上线成功？
踩坑记录：遇到了什么问题？怎么解决的？

示例：

> 内部知识库问答 Agent
> - 背景：公司文档分散在多个系统，员工查询效率低
> - 权限：按部门隔离文档访问范围，技术支持只能查技术文档
> - 取舍：放弃通用 RAG，选择 GraphRAG 提升查询准确率
> - 验收：P95 响应时间 < 3s，权限误判率 < 0.1%
> - 踩坑：初期未做权限缓存，高频查询时数据库压力大，后引入 Redis 缓存权限信息

---