一问一答，说清楚。

我会分成控制面、运行面和治理面。控制面管理 Skill、Prompt、模型、工具、权限和版本；运行面负责路由、状态、记忆、工具调用、断点续跑和预算；治理面负责鉴权、审计、观测、评测、人工审批、降级和回滚。

请求先识别租户和权限，再判断适合工作流、RAG 还是 Agent。执行过程中限制步骤数、Token、时延和可调用工具，每一步都有状态和错误码，失败时可以重试、恢复、降级或转人工。

审批、表单、金额校验和状态流转这类节点明确的任务，优先用规则、代码或工作流；企业知识问答使用 RAG；只有需要根据上下文决定下一步并调用多个工具的任务，才使用 Agent。

如果传统代码能稳定解决，就不应该为了使用 AI 增加不确定性。我在 AI-OA 中就是把审批和表单放进固定流程，知识问答走 RAG，跨系统操作才交给 Agent。

普通 ReAct 让模型自己决定下一步，容易出现循环、参数错误、越权和成本失控。受控 ReAct 会限制状态、工具白名单、参数 Schema、步骤数、Token 和时延。每次工具调用前做权限和参数校验，调用后检查结果；连续失败、重复执行或超过预算就停止、降级或转人工。

不能只相信模型说完成了。我会结合结构化完成状态、输出 Schema、业务结果和下游系统返回码。例如修改订单必须确认下游系统真的返回成功；知识问答要确认有足够证据。连续几步没有新状态或重复调用同一工具时，判定为无进展并停止。

我的设计原则是按生命周期和用途分层，而不是把所有历史塞进 Prompt。短期记忆用于当前步骤和任务状态，长期记忆用于稳定的用户或业务信息，知识库内容通过 RAG 管理，不和用户状态混在一起。每一层都要明确存储位置、权限、过期策略和召回方式。

先做文档解析、清洗、切分和元数据提取，再生成向量。检索时结合关键词和向量召回，先做租户与权限过滤，再重排、压缩上下文，要求模型基于证据回答；证据不足时拒答或转人工。

评测会区分 Recall@K、MRR 或 nDCG、答案准确率、引用正确率、拒答准确率、延迟和成本，不能只看回答是否像人话。

知识缺失优先 RAG；输出格式问题先用 Prompt 和结构化输出；固定流程使用规则或工作流；稳定的领域行为和表达方式、且有足够高质量样本时再考虑 SFT 或 LoRA；DPO 更适合偏好排序。我会先做简单方案基线，再比较准确率、覆盖率、延迟、成本和安全指标。

MCP 只是工具接入协议，服务端仍要做身份认证、租户权限、参数 Schema、超时、限流、幂等和审计。工具需要白名单，不能让模型任意执行 Shell、SQL 或访问 URL；高风险写操作要人工确认，外部文档和工具返回内容只能当作不可信数据。

CLI 工具要包装成固定输入输出的接口，约定 JSON 参数、退出码、超时、工作目录、网络权限和错误格式，再注册到 Skill 或 MCP 工具目录中。

租户信息要从认证开始贯穿请求、记忆、向量检索、缓存、日志和工具调用。检索前必须做权限过滤，不能等回答生成后再补救；不同租户不能共享上下文缓存；工具服务端要再次校验权限；敏感数据要脱敏、加密并审计。私有化部署还要限制外网出口。

参数错误和权限错误一般不重试；网络超时或临时 5xx 可以有限重试。写操作必须有幂等键，避免重复扣款或重复发货。下游持续失败就熔断，切备用方案或转人工；已经产生部分副作用时，需要补偿操作或人工确认。

我会把一次请求拆成 trace 和多个 span，分别记录模型调用、Prompt、检索、工具调用和状态变化，同时记录模型版本、Skill 版本、Token、时延、错误码、租户和人工接管原因。

线上看成功率、人工接管率、工具失败率、循环率、P95 延迟和成本；离线看任务完成率、答案准确率、工具参数正确率和安全攻击样本。每次 Prompt、模型、Skill 或知识库变更都跑固定回归集。

路由要同时考虑任务能力、上下文长度、结构化输出能力、负载、成本、延迟和数据合规，而不是只看模型名称。策略要版本化，按租户或流量灰度。降级时可以切换同能力模型、缩短上下文、改成检索结果返回，或者转人工。

SSE 卡顿要检查事件边界、flush、心跳、客户端断连和背压，不能只在最后一次性返回。

我的生产系统主要使用自研状态机和受控 ReAct。LangGraph 的状态、节点、边和检查点思想与我的实现接近；AutoGen 的多 Agent 协作思路我了解，但没有把没有长期生产使用的框架说成深度经验。对我来说，状态管理、权限、工具调用、评测和失败恢复比框架名称更重要。

我会先拆分确定性和非确定性部分。权限、金额、状态流转等核心约束保留在规则或工作流中；自然语言理解、知识查询和多工具协同再交给 Agent。这样既能提供智能能力，也不会把关键业务约束交给模型。

我会先确认准确率指的是检索、回答、流程完成还是业务结果。高风险场景不能只依赖模型，可以采用分级策略：低风险自动处理，中风险生成建议并人工确认，高风险只做辅助和留痕。通过证据、权限、规则、人工审批和拒答机制控制错误。

先定位问题属于数据、召回、模型、Prompt 还是流程设计。如果达不到风险要求，就缩小自动化范围，从自动执行改成推荐、草稿或人工辅助。先交付风险可控的 MVP，再根据真实数据迭代，而不是把不成熟的模型直接放进关键流程。

先确认数据、权限和网络边界，再梳理现有系统、接口、账号和操作流程。选择低风险、可量化的试点，建立基线和验收指标，先影子运行再灰度上线，同时保留人工接管、审计和回滚，最后补齐运维、培训、文档和应急预案。

我会把争论转成可验证的问题，先统一目标指标、数据集、风险边界和时间限制，再做小规模 POC 或回放测试。这样比较的是结果和代价，而不是模型名称或个人偏好。无法马上解决的部分，先做风险可控的 MVP。

第一个月梳理现有 Agent、Skill、模型、工具、数据权限和线上问题，建立架构和指标视图。第二个月选一个高价值、低风险场景，补齐运行时约束、观测、评测和人工接管。第三个月把验证过的能力沉淀成 Skill、SDK、发布流程和模板，推动第二个场景复用。

我从 2023 年开始持续做 Agent 安全、NLP 和模型评测，2024 年开始进入正式的大模型算法岗位。正式工作经历按公司任职计算还不到三年，但已经经历了模型选型、Agent 架构、RAG、推理部署、生产治理和业务交付完整链路。我会把正式任职和项目经历分开说明，不夸大年限。

我这里说的负责人，主要是技术方向和项目交付负责人，不把它和正式行政管理混为一谈。我的职责包括判断业务问题适合什么技术路线、拆解研发任务、确定优先级、处理跨团队依赖、亲自完成关键模块，并对最终上线结果负责。

我有项目推进、客户协作和跨团队交付经验，也做过项目经理、需求分析、测试和上线切换。正式直属人员管理经验还在积累，但我熟悉任务拆解、接口约定、技术评审、风险跟进和交付推进。下一步希望把技术和项目负责人经验扩展到团队管理和平台建设上。

公司的业务方向近期发生了调整，大模型微调相关投入有所收缩，而我希望继续深耕大模型、Agent 平台和企业应用落地。因此希望寻找一个技术方向更匹配、能够持续投入的平台。

我并不只做微调。我的经历覆盖 Agent 运行时、RAG、模型路由、网关、MCP、推理服务、评测和业务交付。微调只是其中一部分，我更擅长根据业务约束判断什么时候使用工作流、RAG、Agent、规则或模型训练，并把方案真正部署上线。

我在完整等保、密评和组织级平台治理方面的经历还没有覆盖所有环节。已有经验主要集中在认证、访问控制、审计、运行时约束和生产可靠性。正式合规项目中，我会和安全、基础设施团队共同把要求前置到架构设计和验收标准里。