1. 为什么“能跑”的 Agent 一进业务就废我最早做 Agent 接入的时候踩过一个特别典型的坑。Demo 阶段一切顺利本地跑个脚本模型能调工具、能查数据、能返回结果演示给同事看的时候大家都觉得“这东西能落地”。结果一接进真实的业务系统问题全冒出来了——上下文对不上、权限校验过不去、运行时环境不一致、并发一上来就乱套。那种感觉就像你辛辛苦苦组装了一台车在自家院子里开得好好的一上高速就发现方向盘是歪的、刹车是软的。这个问题的本质其实不是模型不够聪明而是我们把“Agent 能跑”和“Agent 能进业务流程”当成了同一件事。前者只需要一个能推理的模型加几个工具函数后者需要一整套围绕上下文管理、权限控制、运行时隔离和流程编排的工程体系。标题里说的“从上下文到权限”恰好点出了这条链路上最关键的两个卡点上下文决定了 Agent 能不能“看懂”业务权限决定了 Agent 能不能“动得了”业务。我写这篇东西是想把我在实际项目里趟过的路整理出来。适合谁看如果你正在做 Agent 开发尤其是准备把 Agent 从原型推进到生产环境的阶段那这些内容应该能帮你少走一些弯路。如果你还在 Demo 阶段也可以提前了解一下后面会遇到什么。全文会围绕四个核心板块展开整体架构怎么设计、上下文工程怎么做、权限体系怎么搭、运行时怎么隔离最后再聊聊常见问题和排查思路。2. 整体架构设计Agent 接入业务的分层思路2.1 为什么不能把 Agent 当成一个“大函数”来用很多人第一次做 Agent 接入思路是这样的写一个主函数里面调模型、解析输出、执行工具、返回结果完事。这个思路在单轮、单用户、单任务的场景下没问题但一旦接入真实业务流程就会遇到几个绕不过去的坎。第一个坎是状态管理。业务流程往往是有状态的用户可能分好几步完成一个操作中间还要查数据、确认信息、回退修改。如果 Agent 每次调用都是无状态的那它根本记不住上一轮聊了什么更别提理解业务上下文了。第二个坎是权限边界。在 Demo 里Agent 调工具就是直接调没人管你有没有权限。但在业务系统里不同角色能做的事完全不同。一个普通员工让 Agent 去查财务报表这显然不行。权限必须在 Agent 执行工具之前就卡住而不是等工具执行完了再报错。第三个坎是运行时隔离。Agent 执行的任务可能涉及文件操作、网络请求、数据库读写这些操作如果和主业务系统跑在同一个进程里一旦 Agent 行为异常整个业务系统都可能受影响。所以运行时必须做隔离让 Agent 在一个受控的环境里执行。基于这些考虑我一般会把 Agent 接入业务分成四层接入层、编排层、执行层、基础设施层。接入层负责和业务系统对接处理请求路由和协议转换编排层负责上下文组装、任务规划和流程控制执行层负责工具调用和权限校验基础设施层提供运行时隔离、日志监控和资源管理。这个分层不是拍脑袋定的而是根据实际项目里反复调整后沉淀下来的。2.2 四层架构的职责划分与数据流先说说接入层。这一层最容易被忽视但它的作用很关键。业务系统可能通过 HTTP、消息队列、RPC 等各种方式发来请求接入层要做的就是把这些异构的请求统一成 Agent 能理解的格式。同时接入层还要负责身份识别——这个请求是谁发的、属于哪个租户、有什么角色。这些信息会一路传递到执行层作为权限校验的依据。编排层是 Agent 的“大脑”。它拿到请求后首先要做的是上下文组装从会话历史、业务数据、用户画像、知识库里抽取相关信息拼成模型能理解的上下文。然后根据任务类型选择合适的 Agent 策略——是单轮工具调用还是多轮规划执行还是需要人工介入的审批流程。编排层还要处理异常和重试比如模型输出格式不对、工具调用超时、权限校验失败等情况。执行层是 Agent 的“手脚”。它负责实际调用工具和 API但在调用之前必须过权限校验这一关。权限校验的逻辑我后面会详细讲这里先提一点权限校验不能只做一次而是要在工具调用的每个环节都做。比如一个数据库查询工具不仅要校验用户有没有查询权限还要校验查询的表、字段、行级条件是否符合权限规则。基础设施层提供运行时环境。我一般会用容器或沙箱来隔离 Agent 的执行环境确保它只能访问被授权的资源。同时基础设施层还要提供日志、监控、限流、熔断等能力保证 Agent 的行为可观测、可控制。这四层之间的数据流是这样的接入层收到请求后提取身份信息和业务参数传给编排层编排层组装上下文、规划任务把工具调用请求发给执行层执行层校验权限后在基础设施层提供的隔离环境中执行工具把结果返回给编排层编排层根据结果决定下一步动作最终把响应返回给接入层。2.3 架构选型时容易踩的坑在实际项目里架构选型有几个常见的坑。第一个坑是过度设计。有些人一上来就搞微服务、搞消息队列、搞分布式编排结果系统复杂度飙升调试成本极高。我的建议是如果业务量不大先用单体架构把流程跑通等确实遇到性能瓶颈了再拆分。第二个坑是上下文和编排耦合太紧。有些实现把上下文组装逻辑直接写在编排层里导致上下文一变编排逻辑也要跟着改。更好的做法是把上下文管理抽成独立的模块编排层只负责调用上下文接口不关心上下文具体怎么组装。第三个坑是权限校验后置。我见过一些实现是等工具执行完了再检查权限发现没权限就回滚。这种做法在简单场景下能用但在涉及外部系统调用、消息发送、资金操作等场景下回滚根本不可能。权限校验必须在工具执行之前完成。第四个坑是运行时环境不一致。开发环境用的是本地 Python 环境测试环境用的是 Docker生产环境用的是 K8s结果 Agent 在不同环境下的行为不一致。这个问题在接入真实业务流程时特别致命因为业务流程往往依赖特定的库版本、环境变量、网络配置。解决办法是尽量保持运行时环境的一致性用容器镜像把依赖固化下来。3. 上下文工程让 Agent 真正“看懂”业务3.1 上下文不只是聊天记录很多人对上下文的理解还停留在“把聊天记录拼起来发给模型”这个层面。这在通用对话场景下勉强够用但在业务流程里远远不够。业务流程的上下文至少包含四个维度会话上下文、业务上下文、用户上下文、知识上下文。会话上下文是用户和 Agent 的交互历史包括用户说了什么、Agent 回了什么、调用了哪些工具、得到了什么结果。这部分比较好理解但要注意的是会话上下文不能无限增长需要做截断或摘要。我一般会根据模型的上下文窗口大小保留最近 N 轮对话更早的对话用摘要代替。业务上下文是当前任务相关的业务数据。比如用户要让 Agent 帮忙处理一个订单那订单的详细信息、订单状态、关联的客户信息、物流信息都属于业务上下文。这部分数据往往不在对话历史里需要 Agent 主动去查或者在请求进来时就预加载好。用户上下文是用户的身份、角色、权限、偏好等信息。这部分数据决定了 Agent 能做什么、不能做什么以及应该用什么风格和用户交互。比如同样是查数据管理员能查全量数据普通员工只能查自己部门的数据这个差异就体现在用户上下文里。知识上下文是业务规则、操作手册、常见问题等静态知识。这部分数据一般放在知识库里Agent 需要的时候通过检索获取。知识上下文的质量直接影响 Agent 的回答准确性所以知识库的建设和维护很重要。3.2 上下文组装的具体策略与参数计算上下文组装的核心问题是怎么在有限的上下文窗口里塞进最有用的信息。模型的上下文窗口是有限的比如 8K、32K、128K甚至现在有些模型支持 1M 上下文。但窗口大不代表可以随便塞因为上下文越长推理成本越高延迟越大而且模型对长上下文的注意力也会衰减。我一般会用这样的策略来组装上下文首先系统提示词占固定比例大概 10% 到 15%这部分包含 Agent 的角色定义、行为规范、输出格式要求。然后用户上下文和业务上下文占 20% 到 30%这部分是当前任务的关键信息必须优先保证。接着知识上下文占 20% 到 30%根据任务相关性动态检索。最后会话历史占剩下的部分越近的对话权重越高。具体怎么计算呢假设模型上下文窗口是 32K token系统提示词用了 4K用户和业务上下文用了 8K知识上下文用了 8K那留给会话历史的就是 12K。如果一轮对话平均 500 token那大概能保留 24 轮。超出部分就要做摘要或者丢弃。这里有个细节要注意不同模型对 token 的计算方式不一样中文和英文的 token 比例也不同。我一般会用模型对应的 tokenizer 来精确计算而不是粗略估算。另外工具调用的结果往往很长比如一个数据库查询可能返回几百行数据这些数据不能直接塞进上下文需要做裁剪或摘要。3.3 上下文压缩与摘要的实操技巧上下文压缩是个技术活。我试过几种方案各有优劣。第一种是滑动窗口只保留最近 N 轮对话简单粗暴但有效。缺点是早期的重要信息会丢失。第二种是摘要压缩用模型把早期对话总结成一段话保留关键信息。缺点是摘要本身会引入误差而且摘要也需要消耗 token。第三种是向量检索把历史对话存到向量库需要的时候检索相关片段。缺点是检索质量不稳定而且增加了系统复杂度。我现在的做法是组合使用最近 5 轮对话保留原文5 到 20 轮做摘要20 轮以上的存向量库按需检索。这样既保证了近期对话的完整性又保留了远期对话的可追溯性。摘要的 prompt 我一般这样写“请把以下对话总结成不超过 200 字的摘要保留用户的核心需求、Agent 的关键动作、重要的业务数据和未解决的问题。不要添加对话中没有的信息。”这个 prompt 的关键是明确摘要的长度、内容和边界避免模型自由发挥。还有一个技巧是结构化上下文。与其把上下文拼成一大段文本不如用结构化的格式组织比如 JSON 或 XML。这样模型更容易理解各个部分的边界和含义。比如{ system: 你是一个订单处理助手..., user_profile: { user_id: U12345, role: customer_service, department: east_region }, business_data: { order_id: O67890, status: pending, amount: 299.00 }, conversation_history: [ {role: user, content: 帮我查一下这个订单}, {role: assistant, content: 好的订单 O67890 当前状态是待处理...} ] }这种结构化格式的好处是可读性强、易于程序处理、模型理解准确。缺点是会占用更多 token因为标签本身也要算 token。所以要在结构化和 token 效率之间做权衡。3.4 上下文污染的识别与清理上下文污染是我在实际项目里遇到的最头疼的问题之一。所谓上下文污染就是上下文里混入了错误、过时、矛盾的信息导致模型输出异常。常见的污染源有几个工具调用返回了错误数据、用户输入了误导性信息、多轮对话中信息被覆盖、知识库检索到了不相关的文档。识别上下文污染的方法有几个。一是输出异常检测如果模型输出明显不符合业务规则比如金额算错了、状态判断错了那很可能是上下文有问题。二是上下文审计在组装上下文的时候记录每个片段的来源和版本出问题的时候可以追溯。三是一致性校验检查上下文里有没有矛盾的信息比如订单状态同时是“已支付”和“待支付”。清理上下文污染的策略要看具体情况。如果是工具返回了错误数据那要修复工具或者加数据校验。如果是用户输入了误导性信息那要在上下文里标注信息的可信度。如果是多轮对话信息覆盖那要明确信息的时效性让模型知道哪个是最新的。如果是知识库检索问题那要优化检索策略或者清洗知识库。我一般会在上下文组装的时候加一个清洗步骤把明显的噪声去掉比如重复的内容、格式错误的片段、过期的数据。同时我会给每个上下文片段打上元数据标签比如来源、时间、可信度让模型在推理的时候能参考这些信息。4. 权限体系Agent 执行工具的“安全阀”4.1 权限模型的设计从 RBAC 到 ABACAgent 的权限模型设计我建议从 RBAC 起步逐步过渡到 ABAC。RBAC 是角色基础访问控制核心思想是给角色分配权限给用户分配角色。比如管理员角色能查所有数据普通员工角色只能查自己的数据。RBAC 的优点是简单直观缺点是粒度粗难以处理复杂的权限场景。ABAC 是属性基础访问控制核心思想是根据用户属性、资源属性、环境属性动态判断权限。比如“部门经理在工作时间能查本部门的订单数据”这条规则就涉及用户角色、资源归属、时间等多个属性。ABAC 的优点是灵活缺点是规则复杂维护成本高。在实际项目里我一般会用 RBAC 做粗粒度控制用 ABAC 做细粒度控制。比如先用 RBAC 判断用户有没有“查询订单”这个权限再用 ABAC 判断用户能查哪些订单。这样既保证了权限模型的简洁性又满足了业务场景的灵活性。权限模型的设计还要考虑权限继承和权限委托。权限继承是指子角色自动拥有父角色的权限比如“高级客服”继承“普通客服”的权限。权限委托是指用户可以把部分权限临时授予他人比如经理出差时把审批权限委托给副经理。这两种机制在业务流程里很常见设计权限模型时要预留支持。4.2 工具调用的权限校验流程工具调用的权限校验我一般会分成三个环节调用前校验、调用中校验、调用后审计。调用前校验是最关键的。当编排层决定要调用某个工具时执行层首先要检查用户有没有调用这个工具的权限。这个检查包括用户角色是否允许调用该工具、用户是否有该工具所需的数据权限、当前环境是否满足调用条件。比如一个“删除订单”的工具只有管理员角色能调用而且只能删除自己管辖范围内的订单而且只能在订单未发货的状态下调用。调用中校验是在工具执行过程中做的检查。有些工具的权限不是一次性判断的而是要根据执行过程中的数据动态判断。比如一个“批量查询订单”的工具用户有查询权限但查询结果里可能包含敏感字段这时候就要在返回结果前做字段级权限过滤。行级权限也是类似的道理用户能查订单但只能查自己部门的订单这个过滤要在查询执行时完成。调用后审计是在工具执行完成后做的记录和检查。每次工具调用都要记录谁调的、调了什么、传了什么参数、返回了什么结果、耗时多少、是否成功。这些日志不仅用于问题排查也用于安全审计。如果发现异常调用比如某个用户短时间内大量调用敏感工具可以触发告警或自动阻断。4.3 行级权限与字段级权限的实现行级权限和字段级权限是业务系统里最常见的细粒度权限需求。行级权限控制用户能看到哪些数据行字段级权限控制用户能看到哪些字段。行级权限的实现方式有几种。一种是在 SQL 查询里加过滤条件比如WHERE department east_region。这种方式简单直接但需要把权限规则翻译成 SQL 条件而且对非 SQL 数据源不适用。另一种是在应用层做过滤查询出数据后在内存里筛选。这种方式灵活但性能差数据量大时不可行。还有一种是用数据库的行级安全策略比如 PostgreSQL 的 Row Level Security。这种方式性能好但依赖特定数据库。我一般会根据数据源和性能要求选择方案。对于关系型数据库优先用 SQL 过滤或数据库行级安全。对于 API 数据源在应用层做过滤。对于大数据量场景考虑用视图或物化视图预计算权限过滤后的数据。字段级权限的实现相对简单主要是在返回结果前做字段裁剪。比如用户没有查看“客户手机号”的权限那返回结果里就把这个字段去掉或脱敏。字段级权限的难点在于权限规则的维护因为字段很多每个字段的权限可能不同。我一般会用配置化的方式管理字段权限比如用一个 JSON 配置描述每个角色能访问哪些字段。4.4 权限校验的常见漏洞与加固权限校验最容易出的问题是校验遗漏。比如某个工具调用路径忘了加权限校验或者某个分支条件下跳过了校验。这种问题在代码审查时很难发现因为权限校验逻辑往往分散在各个地方。我的做法是把权限校验做成统一的拦截器或中间件所有工具调用都必须经过这个拦截器避免遗漏。第二个问题是权限提升。比如用户通过构造特殊参数让 Agent 调用了超出权限的工具。这种问题常见于参数校验不严的场景。解决办法是对所有输入参数做严格校验尤其是涉及资源 ID、操作类型、范围条件的参数。第三个问题是权限缓存。为了提高性能有些实现会缓存权限判断结果。但如果权限规则变了缓存没及时更新就会出现权限不一致。解决办法是设置合理的缓存过期时间或者在权限规则变更时主动失效缓存。第四个问题是权限日志缺失。有些实现只记录工具调用成功或失败不记录权限校验的过程。这样出问题时很难追溯。我的做法是记录每次权限校验的输入、规则、结果方便审计和排查。5. 运行时隔离让 Agent 在受控环境中执行5.1 为什么需要运行时隔离运行时隔离的核心目的是限制 Agent 的行为范围防止它意外或恶意地影响业务系统。Agent 在执行任务时可能会读写文件、发起网络请求、调用系统命令、访问数据库。这些操作如果不加限制可能会造成数据泄露、服务中断、资源耗尽等问题。我见过一个案例Agent 在执行“清理临时文件”任务时因为路径拼接错误把业务数据目录给删了。还有一个案例Agent 在调用外部 API 时因为没设超时请求一直挂起把线程池耗尽了。这些问题在 Demo 阶段不会暴露但一上生产就可能造成严重事故。运行时隔离的手段有几种进程隔离、容器隔离、沙箱隔离、网络隔离。进程隔离是把 Agent 跑在独立进程里通过 IPC 通信。容器隔离是用 Docker 或类似技术把 Agent 跑在容器里限制资源使用和文件系统访问。沙箱隔离是用 seccomp、AppArmor 等机制限制系统调用。网络隔离是用网络策略限制 Agent 能访问的地址和端口。5.2 容器化运行时的配置要点容器化是我最常用的运行时隔离方案。用 Docker 把 Agent 的执行环境打包可以保证环境一致性同时限制资源使用。配置容器时有几个要点。第一是基础镜像的选择。我一般会用精简的基础镜像比如 alpine 或 distroless减少攻击面。但要注意精简镜像可能缺少某些依赖库需要根据 Agent 的实际需求选择。第二是资源限制。用--memory和--cpus限制容器的内存和 CPU 使用防止 Agent 耗尽宿主机资源。同时设置--pids-limit限制进程数防止 fork 炸弹。第三是文件系统限制。用--read-only把容器文件系统设为只读需要写入的目录用 volume 挂载。这样即使 Agent 被攻破也无法修改系统文件。第四是网络限制。用--network指定网络模式默认用 none 或自定义网络只开放必要的端口。如果需要访问外部服务用网络策略限制目标地址。第五是用户权限。用--user指定非 root 用户运行容器减少权限提升的风险。一个典型的 Docker 运行命令大概是这样docker run \ --rm \ --memory 512m \ --cpus 1.0 \ --pids-limit 100 \ --read-only \ --tmpfs /tmp:size64m \ --network agent_net \ --user 1000:1000 \ -v /data/agent_workspace:/workspace:rw \ agent_runtime:latest这个配置限制了内存 512M、CPU 1 核、进程数 100文件系统只读但 /tmp 可写网络用自定义网络以非 root 用户运行工作目录挂载到宿主机。5.3 工具调用的超时、重试与熔断Agent 调用工具时必须设置超时。没有超时的工具调用就像没有刹车的车一旦出问题就是大问题。超时时间要根据工具的类型和业务要求来定。查询类工具一般 5 到 10 秒写入类工具 10 到 30 秒批量处理类工具可以更长但要有进度反馈。重试策略要谨慎。不是所有失败都适合重试。网络超时可以重试参数错误重试也没用权限不足重试更没用。我一般只对幂等的、临时性失败的调用做重试重试次数不超过 3 次每次重试间隔递增。熔断是为了防止故障扩散。如果某个工具连续失败多次就暂时停止调用它直接返回失败等一段时间后再尝试恢复。这样可以避免 Agent 在工具不可用时反复重试浪费资源。限流是为了防止 Agent 过度调用工具。可以按用户、按工具、按时间窗口设置限流规则。比如每个用户每分钟最多调用 10 次查询工具每个工具每秒最多处理 100 次调用。5.4 运行时日志与可观测性建设运行时日志是可观测性的基础。我一般会记录几类日志请求日志、工具调用日志、权限校验日志、异常日志、性能日志。请求日志记录每个进入系统的请求包括请求 ID、用户 ID、时间戳、请求内容。工具调用日志记录每次工具调用的详细信息包括工具名、参数、结果、耗时、是否成功。权限校验日志记录每次权限判断的输入、规则、结果。异常日志记录所有异常和错误包括堆栈信息。性能日志记录关键环节的耗时用于性能分析。日志的格式我建议用结构化格式比如 JSON方便后续的检索和分析。日志的存储要考虑容量和保留时间一般热数据保留 7 天冷数据归档到对象存储。除了日志还要有指标和链路追踪。指标包括请求量、成功率、延迟、资源使用率等用 Prometheus 或类似工具采集。链路追踪用 Trace ID 把一次请求涉及的所有调用串起来方便定位问题。6. 常见问题与排查技巧实录6.1 上下文相关问题的排查上下文相关的问题最常见的是模型输出不符合预期。排查思路是这样的首先检查上下文里有没有明显的错误信息比如数据格式不对、字段缺失、内容矛盾。然后检查上下文长度有没有超出模型窗口超出的话模型可能会截断或忽略部分内容。接着检查上下文的顺序重要的信息应该放在前面或后面中间部分容易被模型忽略。最后检查上下文的格式结构化的上下文比纯文本更容易被模型理解。还有一个常见问题是上下文丢失。比如多轮对话中模型突然忘了之前说过的信息。这通常是因为上下文截断导致的。解决办法是调整截断策略保留更长的历史或者用摘要保留关键信息。6.2 权限校验失败的典型场景权限校验失败的原因有很多我整理了一个速查表问题现象可能原因排查方法解决方案工具调用被拒绝用户角色无权限检查用户角色和工具权限配置调整角色权限或申请授权查询结果为空行级权限过滤检查行级权限规则调整权限规则或数据范围字段显示为脱敏字段级权限限制检查字段权限配置调整字段权限或申请授权权限校验超时权限服务响应慢检查权限服务性能优化权限服务或加缓存权限规则不生效缓存未更新检查权限缓存清除缓存或缩短过期时间6.3 运行时环境不一致的排查运行时环境不一致的表现是同样的代码在开发环境能跑在测试环境报错在生产环境又不一样。排查这类问题我一般会从几个方面入手。首先是依赖版本。检查不同环境的 Python 版本、库版本是否一致。用pip freeze导出依赖列表对比不同环境的差异。解决办法是用容器镜像固化依赖。其次是环境变量。检查不同环境的环境变量配置是否一致尤其是数据库连接、API 地址、密钥等。解决办法是用配置管理工具统一管理环境变量。然后是网络配置。检查不同环境的网络策略、DNS 配置、代理设置是否一致。解决办法是用基础设施即代码的方式管理网络配置。最后是文件系统。检查不同环境的文件路径、权限、挂载点是否一致。解决办法是用统一的目录结构和权限配置。6.4 性能问题的定位与优化Agent 接入业务后的性能问题通常表现为响应慢、吞吐低、资源占用高。定位性能问题我一般会用分段计时的方法在请求处理的关键环节打时间戳看哪个环节耗时最长。常见的性能瓶颈有几个。一是上下文组装慢尤其是涉及大量数据查询和知识库检索时。优化方法是加缓存、并行查询、预加载。二是模型推理慢尤其是上下文很长时。优化方法是压缩上下文、用更快的模型、做流式输出。三是工具调用慢尤其是外部 API 调用。优化方法是加超时、重试、熔断、缓存。四是权限校验慢尤其是规则复杂时。优化方法是加缓存、简化规则、异步校验。6.5 独家避坑技巧汇总最后分享几个我在实际项目里总结的避坑技巧。第一个技巧是给 Agent 加“刹车”。不管 Agent 多聪明都要有兜底机制。比如设置最大执行步数超过就停止设置最大工具调用次数超过就报错设置最大执行时间超时就中断。这些限制看起来简单但关键时刻能防止 Agent 失控。第二个技巧是权限校验要“双重确认”。对于敏感操作比如删除数据、发送消息、资金操作不仅要校验权限还要加人工确认或二次审批。Agent 可以发起操作但最终执行要有人把关。第三个技巧是上下文要“可追溯”。每次组装上下文时记录每个片段的来源和版本。出问题的时候可以快速定位是哪个片段导致的。这个习惯在排查复杂问题时特别有用。第四个技巧是运行时环境要“可复现”。用容器镜像、配置管理、基础设施即代码保证任何环境都能一键复现。这样出问题时可以在本地复现大大提高排查效率。第五个技巧是日志要“结构化”。不要用纯文本日志用 JSON 格式方便检索和分析。日志里要包含 Trace ID方便串联一次请求的所有调用。第六个技巧是监控要“有告警”。光有监控数据不够还要设置告警规则。比如错误率超过阈值、延迟超过阈值、资源使用率超过阈值都要触发告警。告警要能及时通知到人不能只躺在监控面板里。我在实际项目里最大的体会是Agent 接入业务不是一蹴而就的事而是一个不断迭代的过程。先跑通核心流程再逐步完善上下文管理、权限控制、运行时隔离。不要一开始就追求完美而是要在实践中发现问题、解决问题。每次踩坑都是一次学习的机会把踩过的坑记录下来下次就能避开。