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

为什么Agent Demo跑得丝滑，一上线就翻车？真正卡住程序员的不是模型

news 2026/8/6 20:24:39

聊《岗位变化这么快，程序员职业规划真正该补的是什么？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上周评审会上，一个刚做完的 Agent 项目又被卡住了。前端展示得很漂亮，Prompt 调得也顺，用户输入一句话，模型能给出完整回答，流程看着没问题。但问到上线验收的时候，团队哑了：权限怎么控制？谁调了模型、花了多少钱、延迟多少？出了问题往哪查？这些没人写进需求文档。

我在这个项目里做了技术负责人，最后只能把 Demo 砍掉，先花两周把权限、日志、可观测性补齐再谈上线。这事儿让我意识到，大模型时代的程序员职业路线，早就不是"会调 API 就能吃饭"了。

岗位趋势：招聘JD在悄悄变

前两年转大模型的风口，确实让很多只会调接口的程序员拿到了 offer。但现在再看招聘网站，JD 里出现频率最高的词已经不是"熟悉 LangChain"或者"有 RAG 经验"了，而是这些：

有生产环境 Agent 上线经验
熟悉权限控制和审计日志
具备可观测性设计能力
能处理模型调用的异常和降级

我最近面试了几个候选人，有一个简历写得漂亮，做过三个 Agent 项目，但一问"你的 Agent 怎么控制调用权限"，回答是"用的是模型自带的功能"。再问"线上出问题了怎么排查"，回答是"看控制台日志"。这种回答在 Demo 阶段没问题，但真正上线就会被运维团队打回来。

另一个候选人做过一个智能客服 Agent，项目不大，但他说了一句话让我印象深刻："我在每个工具调用前后都打了结构化日志，包含用户 ID、工具名、输入输出、耗时，出问题的时候直接定位到具体哪一步。"这种思路，才是现在企业真正想要的。

能力分层：谁能吃上饭，谁会被淘汰

我把现在大模型方向的程序员分成三层，每一层面对的职业风险完全不同。

第一层：只会调 API 的调用者。这类人现在最危险。模型能力在快速提升，很多简单的调用场景 AI 自己就能做。你写一个 RAG 检索，可能 Claude Code 几分钟就帮你搞定了。如果你的价值只是"会调用模型接口"，那这个价值在快速贬值。

第二层：能做完整 Agent 应用的开发者。这类人现在还算有市场，但门槛在提高。企业不再满足于"能跑"，而是要"能上线"。你需要理解权限控制、日志采集、异常处理、成本监控这些工程化能力。这一层是当前的主力需求，但竞争也在加剧。

第三层：能设计可观测、可管控的 AI 系统的工程师。这是目前稀缺的群体。企业里能真正把这些东西搭起来的人很少，不是因为技术难，而是因为大多数人没在这个方向上踩过坑、没吃过亏。这一层的人，现在拿到的 offer 溢价明显。

短期学习计划：先补权限和日志这一课

如果你现在想转大模型或者想在现有方向上提升竞争力，我建议你按这个顺序来：

第一阶段：把权限控制搞明白。这不是指 OAuth 那种复杂的身份认证，而是指你的 Agent 在调用工具时，怎么知道当前用户能做什么、不能做什么。我见过太多项目，Agent 能调用所有工具，没有任何限制，上线后被安全团队直接驳回。

一个简单的权限控制思路是这样的：

# 工具权限注册表，不是写死在代码里 TOOL_PERMISSIONS = { "search_knowledge_base": {"roles": ["user", "admin"], "cost_limit_per_call": 0.05}, "query_database": {"roles": ["admin"], "cost_limit_per_call": 0.50}, "send_notification": {"roles": ["user", "admin"], "rate_limit": "10/min"}, "delete_record": {"roles": ["admin"], "require_approval": True}, } def check_tool_permission(user_role: str, tool_name: str, context: dict) -> bool: """每个工具调用前都过一遍这个检查""" if tool_name not in TOOL_PERMISSIONS: return False config = TOOL_PERMISSIONS[tool_name] # 角色检查 if user_role not in config.get("roles", []): log_audit(user_role, tool_name, "denied", "insufficient_role") return False # 频率限制检查 if "rate_limit" in config: if not check_rate_limit(user_role, config["rate_limit"]): log_audit(user_role, tool_name, "denied", "rate_limited") return False # 需要审批的检查 if config.get("require_approval") and not context.get("approved"): log_audit(user_role, tool_name, "denied", "needs_approval") return False return True

这段代码不复杂，但很多项目根本没有这种设计。你可以在自己的 Demo 项目里加上这一层，简历上写"设计了基于角色的工具权限控制机制"，比"用 LangChain 做了个 Agent"有价值得多。

第二阶段：把结构化日志写规范。不是 print 一行日志就完了。你需要记录什么？我总结了一个最小集合：

请求 ID：一次对话的全局标识
用户 ID：谁在调用
时间戳：精确到毫秒
工具名和参数：调了什么、传了什么
模型输出摘要：不是完整输出，是摘要
耗时：每一步花了多久
结果状态：成功/失败/超时/限流

import logging import time import uuid from contextlib import contextmanager # 结构化日志配置 logger = logging.getLogger("agent_audit") logger.setLevel(logging.INFO) handler = logging.FileHandler("agent_audit.log") handler.setFormatter(logging.Formatter( '{"timestamp":"%(asctime)s","request_id":"%(request_id)s",' '"user_id":"%(user_id)s","tool":"%(tool)s",' '"input":"%(input)s","output":"%(output)s",' '"cost_ms":%(cost_ms)s,"status":"%(status)s"}' )) logger.addHandler(handler) @contextmanager def audit_tool_call(user_id, tool_name): """用上下文管理器保证每次工具调用都有日志""" request_id = str(uuid.uuid4())[:8] start = time.time() try: yield {"request_id": request_id, "user_id": user_id, "tool": tool_name} status = "success" except Exception as e: status = f"error:{type(e).__name__}" raise finally: cost_ms = int((time.time() - start) * 1000) logger.info( f"{request_id} {user_id} {tool_name} {status} {cost_ms}ms" )

这个模式很简单，但加上去之后，你的 Agent 就从"黑盒"变成了"可追溯"。运维团队接手的时候，会感谢你的。

第三阶段：把可观测性补齐。日志有了，接下来要解决的是"怎么快速定位问题"。几个关键点：

给每次模型调用设置超时和重试策略，不要让它卡住整个流程
记录 token 消耗，算清楚每次调用的成本
对高频工具调用设置降级策略，模型挂了的时候有没有 fallback
做一个简单的仪表盘，能看到当前有多少请求在跑、平均延迟多少、错误率多少

中期项目沉淀：怎么做一个能写进简历的项目

很多人做项目喜欢做大而全的 Demo，但我建议你做"小而扎实"的项目。企业看项目经验，不是看你做了多少个功能，而是看你是不是处理过真实的问题。

一个能加分的项目应该长这样：

做一个内部的知识问答 Agent，核心功能很简单：用户提问，Agent 检索知识库，给出答案。但你要在以下几个地方下工夫：

1. 权限控制：不同部门的员工能看到不同范围的知识库，Agent 调用检索工具时要带上部门信息做过滤
2. 日志体系：每次问答的完整链路都要记录下来，包括检索到了哪些文档、模型选了哪个、输出了什么
3. 成本监控：统计每天有多少次调用、花了多少 token、哪个时间段最活跃
4. 异常处理：知识库检索失败的时候怎么办？模型超时的时候怎么办？要有明确的降级逻辑

这个项目不需要界面多好看，但你的代码里要有这些细节。面试的时候，你能说出"我在检索工具调用前加了部门权限校验"、"我用结构化日志记录了每次调用的完整链路"、"我设置了 5 秒超时和 2 次重试"，这比说"我用 LangChain 做了一个 RAG 系统"有说服力得多。