别卷 Agent 架构了：大模型上线前的生死线是权限与日志-平芜编程栈

聊《做过大数据的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

很多做大数据的同学转行做大模型工程时，最容易陷入一个误区：觉得只要把 RAG 链路搭起来，或者调通一个 LangChain 的 Demo，就算入门了。

我也经历过这个阶段。去年为了帮团队做内部知识库，我花了两周时间调优 Embedding 模型，换了三个 Vector DB，甚至重构了 Chunking 策略。结果呢？Demo 跑起来效果惊艳，PPT 汇报无懈可击。一旦要对接真实业务系统，要求“不同部门看不同内容”，还要“记录谁查了什么以便追责”，整个系统瞬间崩塌。

这不是算法不行，这是工程化没到位。

现在 2026 年了，大模型应用已经从“能不能跑通”进入了“敢不敢上线”的阶段。对于数据工程师来说，你真正的护城河不是会写 Prompt，而是能否处理权限隔离、细粒度日志和全链路可观测性。今天我不谈复杂的 Agent 编排，只聊聊我们怎么把大数据时代的“脏活累活”迁移到 LLM 工程中，解决最棘手的权限与可观测问题。

数据治理的延伸：从 ETL 到 Prompt 安全

在传统数仓，我们有严格的 RBAC（基于角色的访问控制）。但在 LLM 应用中，很多人把 Prompt 当作配置项，随手硬编码。这是大忌。

当模型开始具备 Action 能力（比如调用 API 删除数据、查询用户信息），Prompt 就成了代码的一部分。如果缺乏治理，不仅会有提示词注入风险，更致命的是权限越界。

我在最近的内部项目中，发现了一个典型问题：一个简单的客服 Agent，因为 Prompt 里没有明确的系统级约束，用户在追问“帮我看看我的订单状态”时，模型直接返回了完整的订单详情，包括手机号和地址。这在合规上是重大事故。

我们的解决方案是将“数据治理”思维引入 Prompt 管理：

1. 上下文隔离：不要在 Prompt 里塞入未经脱敏的用户原始数据。
2. 动态权限注入：类似 SQL 的 WHERE 子句，我们在调用模型前，根据当前用户的角色（Role），动态修改 System Prompt 中的指令。

# 错误示范：硬编码权限逻辑 system_prompt = """你是一个客服助手。你可以访问所有用户数据。""" # 正确示范：动态注入权限约束 def build_system_prompt(user_role: str, available_resources: list): base_instruction = """你是一个专业的客服助手。 请注意：你必须严格遵守数据安全规范。 1. 仅允许访问以下资源列表中的数据：{resources} 2. 如果用户请求超出范围，必须拒绝并告知原因。 3. 严禁输出任何 PII (个人身份信息)。""" # 这里可以进一步根据 user_role 调整语气和响应策略 return base_instruction.format(resources=", ".join(available_resources))

这段代码看似简单，但它解决了 Demo 到生产环境最大的鸿沟：确定性。大数据工程师擅长处理结构化数据的权限，现在只需要把这些逻辑映射到非结构化的 Prompt 上下文中。

向量数据库：不只是存 Embedding，更是存“元数据过滤”

很多初学者认为向量数据库（Vector DB）就是一个巨大的向量仓库。错。在生产环境中，向量数据库的核心价值在于混合检索（Hybrid Search），特别是基于元数据（Metadata）的预过滤。

如果你在做权限控制，绝对不能依赖模型来“记忆”谁有什么权限。模型记不住，也不该记。正确的做法是在向量检索阶段就完成权限拦截。

假设我们要构建一个企业知识库 RAG 系统。文档被打上dept: sales,level: internal等标签。当销售部的员工提问时，我们在查询向量之前，先在 Vector DB 层加上dept='sales'的过滤条件。

这样做有两个好处：
1. 性能：缩小了搜索范围，减少了 Embedding 计算的开销。
2. 安全：即使模型产生幻觉，试图编造其他部门的信息，底层检索接口已经物理隔绝了这些数据源。

我之前负责的一个项目，初期没有做元数据过滤，导致在并发高峰期，每次查询都要扫描全量索引，响应时间从 200ms 飙升到 5s。后来引入 Milvus/Pinecone 的 Metadata Filter 功能，配合大数据常见的分区表思路进行索引优化，性能立刻稳定下来。

可观测性：日志是调试黑盒的唯一途径

大模型被称为“黑盒”，因为它的不确定性。在大数据领域，我们有 ETL 任务的监控告警；在大模型领域，我们需要的是Traceable（可追溯）的交互日志。

很多团队只记录最终的输出结果，这是不够的。你需要记录：

输入：用户原始 Query + 检索到的 Context（注意脱敏）。
决策过程：是否触发了 Agent 的工具调用？调用了哪个工具？参数是什么？
延迟分布：向量检索花了多久？LLM 生成花了多久？

没有这些日志，当线上出现“胡言乱语”时，你根本不知道是检索质量差，还是 Prompt 引导错了，或者是模型本身的能力瓶颈。

我们搭建了一套简单的日志采集链路，利用 OpenTelemetry 标准，将每次 LLM 调用的 Span 串联起来。关键的一点是，要在日志中打上user_id和session_id，这样就能复现特定用户的异常路径。

{ "trace_id": "a1b2c3d4...", "span_id": "e5f6g7h8...", "resource": { "service.name": "customer-service-agent" }, "attributes": { "llm.model_name": "qwen-max-latest", "llm.token_count.prompt": 1200, "llm.token_count.completion": 45, "retrieval.score": 0.89, "retrieval.top_k": 3, "permission.check.result": "passed" }, "events": [ {"name": "before_generation", "time": "..."}, {"name": "after_generation", "time": "..."} ] }

注意permission.check.result这个字段。在日志中明确标记权限校验的状态，能帮你快速区分是“业务逻辑错误”还是“安全策略缺失”。

落地建议：如何规划你的转型路径

从大数据转向大模型工程，不要一上来就去学复杂的 GraphRAG 或者多智能体协作。那些是锦上添花，不是雪中送炭。

1. 第一阶段：补齐工程短板。确保你能写出可测试、有日志、有权限控制的 RAG 应用。这是面试和项目交付的底线。
2. 第二阶段：理解模型边界。知道什么任务适合 LLM，什么不适合。比如，简单的分类和实体抽取，传统 NLP 模型往往更快更准，没必要强行上大模型。
3. 第三阶段：探索高级架构。当你解决了稳定性和安全性后，再考虑如何用 LangGraph 等工具编排复杂的工作流。

对于已经在做大数据的同学，你的优势在于对数据流转、存储成本和系统稳定性的敏感度。把这些能力应用到 LLM 的 Context 管理和检索优化上，你会比纯算法背景的工程师走得更远。