Linux 面试实战：进程与线程的区别
2026/10/6 8:03:08
1. 项目概述：当AI Agent必须待在“没网的保险柜”里
你有没有遇到过这种场景：客户把整套系统部署在完全断开互联网的机房里，服务器连ping外网都超时，防火墙策略严到连DNS查询都被拦截——但偏偏，他们又想让AI Agent在内网里跑起来，自动处理工单、分析日志、生成周报，甚至调用内部ERP接口做数据核验。这不是科幻设定，而是金融核心系统、电力调度平台、军工仿真环境、三甲医院HIS系统的日常。所谓“隔离内网”，不是指“网速慢一点”，而是物理或逻辑上彻底切断与公网的任何主动通信通道。在这种环境下谈AI Agent，就像要求一个没有手机信号的消防员，仅靠对讲机和纸质地图，在浓烟密布的楼里完成智能搜救任务。
核心关键词“AI Agent”在这里绝非调用几个OpenAI API那么简单。它意味着需要本地化推理引擎、可离线运行的工具链、无外网依赖的规划与记忆模块、以及一套能在零外部连接下自主决策、容错、回滚的执行框架。而“工程实战”四个字，恰恰点破了当前多数教程的致命短板：它们教你怎么在笔记本上跑通LangChain示例，却从不告诉你，当Agent第一次尝试调用一个不存在的公网API时，整个服务进程卡死30秒后OOM崩溃；也不告诉你，LangGraph的状态机在K8s滚动更新时如何避免状态丢失；更不会提，内网时间不同步导致JWT令牌校验失败这种“一眼看不出毛病”的玄学问题。
我过去三年带团队落地了7个隔离内网AI Agent项目，覆盖银行票据识别、电网故障诊断、药企GMP合规检查等场景。最深的体会是：在隔离内网里做AI Agent，80%的功夫花在“不让它想上网”，而不是“让它更聪明”。这篇文章不讲大模型原理，不堆砌架构图，只聚焦一件事——把一个能真正干活的AI Agent，稳稳当当地塞进那个连curl都打不出去的内网保险柜里。如果你正被“内网怎么部署AI Agent”、“Agent扛不住并发怎么办”、“harness技能包怎么离线加载”这类问题卡住，这篇就是为你写的实操手记。
2. 整体设计思路：先画牢笼，再养猛兽
2.1 为什么不能直接搬开源方案？三个血泪教训
很多团队第一反应是“把LangChain+Ollama打包进Docker，丢进内网就完事”。我试过，也踩过坑。以下是三个真实发生过的故障，每个都导致生产环境停摆超4小时：
故障一：隐性网络探针触发熔断
LangChain的Tool类默认会尝试访问https://api.openai.com做健康检查（即使你根本没配OpenAI Key）。在隔离内网，这个请求会卡在TCP SYN阶段，直到Python默认的60秒超时。而Agent的主循环是同步阻塞的，一个工具初始化失败，整个Agent服务就挂起。我们当时监控看到CPU为0，内存稳定，但所有请求排队——查了两天才发现是这个隐藏的HTTP探针。故障二：动态代码加载引发权限雪崩
某金融客户要求Agent能根据工单类型动态加载Python脚本（比如“票据识别”加载ocr_tool.py，“合同比对”加载diff_tool.py）。我们用了importlib.util.spec_from_file_location。结果上线后发现，Agent容器因SELinux策略限制，无法在运行时读取挂载的工具目录。更糟的是，错误日志只显示ImportError: No module named 'xxx'，根本没提SELinux。最后靠ausearch -m avc -ts recent才定位到拒绝日志。故障三：时间戳漂移导致状态机撕裂
内网NTP服务器配置错误，导致三台Agent节点时间相差12秒。LangGraph的StateGraph依赖datetime.now()生成事件ID。当节点A记录“执行OCR完成”，节点B同时记录“开始OCR”，由于时间戳倒置，状态机判定为逻辑冲突，自动进入interrupted状态并停止响应。重启服务后，未完成的工单全部丢失。
这些不是理论风险，是写在运维事故报告里的真金白银。因此，我们的整体设计哲学是：以“断网”为前提，反向推导所有组件的生存条件。不是“这个库能不能用”，而是“如果它某天突然想联网，我怎么提前掐断它的念头”。
2.2 四层隔离防护体系：从操作系统到应用逻辑
我们最终构建了一个四层防护体系，每层都针对一个关键风险点：
| 防护层 | 目标 | 实现方式 | 验证方法 |
|---|---|---|---|
| L1：网络层物理隔离 | 确保OS级无任何出向连接可能 | 使用iptables DROP所有非内网IP段的OUTPUT规则；禁用/proc/sys/net/ipv4/conf/all/rp_filter防止反向路径过滤误判；删除/etc/resolv.conf中所有nameserver | curl -v http://www.baidu.com必须返回Failed to connect而非超时；nslookup baidu.com必须报server can't find baidu.com |
| L2：运行时环境沙箱 | 阻断Python进程发起网络调用 | 启动Agent前执行export PYTHONHTTPSVERIFY=0 && export HTTP_PROXY="" && export HTTPS_PROXY=""；使用LD_PRELOAD注入自定义so库，hookconnect()系统调用并记录所有尝试连接的目标IP | strace -e trace=connect python -c "import requests; requests.get('http://127.0.0.1')"应只显示本地连接；对外网IP的connect调用应被拦截并打印警告日志 |
| L3：代码层白名单管控 | 禁止任何未授权的网络操作代码执行 | 自研代码扫描器，在CI阶段静态分析所有.py文件，禁止出现requests.get、urllib.request.urlopen、socket.socket.connect等模式；对允许的内网调用（如http://10.10.1.5:8080/api/v1/erp）建立JSON白名单，运行时强制校验URL前缀 | 扫描器报告必须为0 error；运行时若调用非白名单URL，立即抛出NetworkForbiddenError并记录审计日志 |
| L4：Agent行为熔断 | 当Agent逻辑试图越界时紧急刹车 | 在LangGraph的StateGraph每个节点执行前插入pre_node_hook，检查当前state中是否包含external_api_call标记；若存在且目标域名不在白名单，则跳过执行并转入safe_fallback节点 | 模拟一个故意调用https://api.openai.com的测试节点，必须被熔断并进入fallback流程，且不产生任何网络IO |
这四层不是堆砌，而是形成闭环：L1是底线，L2是兜底，L3是预防，L4是纠错。我们曾用这套体系通过某国有银行的三级等保测评，其安全专家现场用Wireshark抓包30分钟，确认无任何出向流量。
2.3 架构选型：为什么放弃LangChain，选择Rust+Actix？
面对隔离内网的严苛要求，我们做了关键取舍：放弃Python生态的便利性，拥抱Rust的确定性。这不是技术炫技，而是工程现实倒逼的选择。
内存确定性：Python的GC不可预测，OOM Killer在内网服务器上常因内存突增杀死Agent进程。Rust的ownership模型保证内存占用恒定。我们用
std::collections::HashMap替代dict，用Arc<RwLock<T>>替代threading.Lock，实测同一负载下，Rust Agent内存波动<3%，Python版波动达37%。启动速度与冷加载：内网服务器多为老旧X86，SSD性能差。Python启动一个LangChain Agent需12秒（加载LLM tokenizer、tool schema、prompt template）。Rust版用
actix-web+llm-chain，冷启动压到1.8秒。这对需要快速扩缩容的工单处理场景至关重要。无依赖二进制分发：
cargo build --release生成的单文件二进制，无需pip install任何包。我们交付给客户的，就是一个agent-server文件，加上一个config.yaml。而Python方案需交付Docker镜像、requirements.txt、甚至编译好的whl包——在无pip源的内网，光解决依赖地狱就能耗掉两天。
当然，Rust学习成本高。我们的折中方案是：核心Agent引擎用Rust，业务工具用Python封装，通过gRPC桥接。即Rust进程作为主控，调用Python子进程（通过subprocess.Popen）执行OCR、数据库查询等重IO操作。这样既保住Rust的稳定性，又不牺牲Python生态的丰富性。gRPC协议本身支持流式传输，即使Python子进程卡死，Rust主进程也能在3秒内检测到并重启它。
3. 核心细节解析：让Agent在“真空”里呼吸
3.1 LLM本地化：不只是下载模型，而是构建可信推理链
在隔离内网，LLM不是“下载一个GGUF文件”就完事。我们必须回答三个问题：模型从哪来？推理是否可信？输出是否可控？
模型来源可信链：我们绝不接受社区随意上传的Qwen或DeepSeek模型。所有模型必须来自上游厂商的官方签名包。例如，DeepSeek官方提供
deepseek-coder-33b-instruct.Q4_K_M.gguf.sig签名文件。我们用gpg --verify deepseek-coder-33b-instruct.Q4_K_M.gguf.sig deepseek-coder-33b-instruct.Q4_K_M.gguf验证。若签名失败，构建流水线立即中断。这是等保要求的硬性条款。推理过程可审计：开源LLM推理库（如llama.cpp）默认不记录token级计算过程。我们打了补丁，在
llama_eval()函数末尾插入回调，将每次llama_decode()的输入logits、输出token ID、采样温度写入环形缓冲区。缓冲区大小固定为1MB，满则覆盖。运维人员可通过curl http://localhost:8080/debug/logits实时查看最后100次推理的logits分布，判断是否存在异常模式（如某token概率长期>0.99，暗示模型被恶意微调）。输出内容强约束：内网Agent输出必须符合格式规范。我们不用正则匹配这种脆弱方案，而是采用结构化输出引导（Structured Output Guidance）。在system prompt中明确要求：“你必须以JSON格式输出，且只包含以下字段：
{"action": "query_db", "params": {"table": "orders", "where": "status='pending'"}}。若无法满足，请输出{"error": "invalid_request", "reason": "xxx"}。”然后在Rust端用serde_json::from_str()解析，失败则触发fallback。实测此法将格式错误率从12%降至0.3%。
提示：不要迷信“模型越大越好”。我们在某电力项目中对比了Qwen2-72B和Qwen2-7B。72B在GPU显存不足时频繁OOM，而7B在INT4量化后，推理速度反而快1.8倍，且准确率仅低0.7个百分点（基于2000条工单测试集）。内网资源有限，要算TCO（总拥有成本），不是参数量。
3.2 工具链离线化：从“调API”到“造轮子”
AI Agent的价值在于调用工具。但在隔离内网，所有“调用”都必须变成“内置”。我们把工具分为三类，并采取不同策略：
内网服务类工具（如ERP、MES）：
这类工具已有内网API。我们不做任何代理，而是用Rust的reqwest库直连，但关键改造有两点：- 连接池预热：Agent启动时，主动对每个内网服务发起3次
HEAD /health请求，确保连接池中有可用连接。避免首个请求因建连耗时过长。 - 证书信任链固化：内网服务多用自签名证书。我们不设
danger_accept_invalid_certs(true)，而是将CA根证书（ca-bundle.crt）编译进二进制。reqwest::ClientBuilder::new().add_root_certificate(Cert::from_pem(include_bytes!("ca-bundle.crt"))?)。这样即使内网CA更新，只需重新编译Agent，杜绝证书过期导致的静默失败。
- 连接池预热：Agent启动时，主动对每个内网服务发起3次
计算密集类工具（如OCR、语音转写）：
这类工具我们彻底替换为轻量级C++实现。例如，OCR不用PaddleOCR（依赖太多Python包），改用Tesseract 5.3的C API封装。编译时加-static-libgcc -static-libstdc++，生成完全静态链接的libocr.so。Rust通过cccrate调用，无需Python解释器。实测Tesseract C API在ARM64服务器上，处理一张A4扫描件比PaddleOCR快2.3倍，内存占用少68%。知识检索类工具（如文档问答）：
放弃ChromaDB等需要后台服务的方案。我们用tantivy（Rust版Lucene）构建纯内存索引。所有PDF/Word文档在Agent启动前，由预处理脚本（doc_preprocessor）提取文本、分块、嵌入（用本地all-MiniLM-L6-v2模型），生成index.tantivy文件。Agent加载时，tantivy::Index::open_in_dir("index.tantivy")，全程无网络、无磁盘IO（索引加载后驻留内存）。搜索延迟稳定在12ms以内。
3.3 状态管理：没有Redis，怎么让Agent记住昨天的事？
隔离内网通常禁用Redis（认为其有网络暴露面）。我们用分层状态存储解决：
瞬时状态（<1秒）：用Rust的
DashMap<String, Value>（线程安全哈希表）存放在内存。用于节点间临时数据传递，如{"current_step": "parse_invoice", "invoice_id": "INV-2024-001"}。会话状态（<1小时）：序列化为MessagePack，存入本地SQLite。表结构极简：
CREATE TABLE sessions (id TEXT PRIMARY KEY, data BLOB, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP)。用WAL模式，PRAGMA journal_mode=WAL，确保高并发写入不锁表。每10分钟触发一次VACUUM清理碎片。长期记忆（>1小时）：写入内网PostgreSQL。但关键改造是记忆压缩算法。原始记忆（如工单对话历史）可能达10MB。我们用
zstd压缩后存入BYTEA字段，解压时用zstd::stream::read::Decoder::new(&data)?。压缩比实测达4.2:1，且ZSTD解压速度是gzip的3倍。
注意：所有状态操作必须带
timeout。例如，SQLite写入超时设为500ms，PostgreSQL查询超时设为2s。超时则降级到内存状态，避免一个慢查询拖垮整个Agent。这是内网低配服务器的生存法则。
4. 实操过程：从零部署一个可运行的内网Agent
4.1 环境准备：三台机器的最小可行配置
我们以一个真实项目为例：为某三甲医院部署“检验报告智能解读Agent”，需接入LIS系统（内网IP10.20.30.10:8080），输出结构化JSON供HIS调用。
| 机器角色 | 硬件配置 | 系统与关键软件 | 用途 |
|---|---|---|---|
| Build Server | 8C16G, 500GB SSD | Ubuntu 22.04, Rust 1.76, Python 3.10, Docker 24.0 | 编译Agent二进制、构建Python工具镜像、签名验证模型 |
| App Server | 4C8G, 256GB SSD | CentOS 7.9, Kernel 5.10, iptables 1.8.7 | 运行Rust Agent主进程，暴露8080端口给内网其他系统 |
| Tool Server | 2C4G, 128GB SSD | Ubuntu 20.04, Python 3.8 | 运行OCR、PDF解析等Python工具子进程，通过gRPC与App Server通信 |
关键步骤：在Build Server上，先执行
sudo sysctl -w net.ipv4.ip_forward=0关闭IP转发，确保它不会意外成为路由。然后用ansible-playbook统一配置三台机器的/etc/hosts，添加10.20.30.10 lis.internal等别名，避免硬编码IP。
4.2 模型与工具准备：离线交付包制作
交付包不是一堆文件，而是一个可验证的tar.gz。结构如下：
hospital-agent-release-v1.2.0/ ├── agent-server # Rust编译好的静态二进制 ├── config.yaml # 配置文件，含内网服务地址、超时时间等 ├── models/ │ ├── deepseek-coder-33b.Q4_K_M.gguf # LLM模型 │ └── deepseek-coder-33b.Q4_K_M.gguf.sig # GPG签名 ├── tools/ │ ├── ocr_tool/ # OCR工具目录 │ │ ├── libocr.so # 静态链接的OCR库 │ │ └── ocr_config.json # Tesseract配置 │ └── pdf_tool/ # PDF解析工具 │ ├── pdf_parser.py # Python脚本 │ └── requirements.txt # 仅含PyPDF2==3.0.1（离线wheel已备好） └── scripts/ └── verify-release.sh # 验证脚本：检查签名、MD5、依赖verify-release.sh核心逻辑：
#!/bin/bash # 1. 验证模型签名 gpg --verify models/deepseek-coder-33b.Q4_K_M.gguf.sig models/deepseek-coder-33b.Q4_K_M.gguf || exit 1 # 2. 检查二进制依赖 ldd agent-server | grep "not found" && exit 1 # 3. 校验MD5（交付前由Build Server生成） echo "a1b2c3... agent-server" | md5sum -c --quiet || exit 1交付时，只给客户hospital-agent-release-v1.2.0.tar.gz和verify-release.sh。客户在App Server上执行./verify-release.sh && tar -xzf ... && ./agent-server --config config.yaml，5分钟内即可启动。
4.3 Agent核心配置：config.yaml详解
config.yaml是Agent的“宪法”，必须精确控制所有行为。以下是关键字段说明：
# 全局配置 server: host: "0.0.0.0" port: 8080 timeout_ms: 30000 # 全局超时，单位毫秒 # LLM配置 llm: model_path: "./models/deepseek-coder-33b.Q4_K_M.gguf" n_ctx: 4096 # 上下文长度，必须≤模型原生支持 n_threads: 4 # 绑定CPU核心数，避免争抢 temperature: 0.3 # 降低随机性，提升输出稳定性 # 工具配置 tools: ocr: endpoint: "http://10.20.30.20:9000" # Tool Server地址 timeout_ms: 10000 pdf_parser: endpoint: "http://10.20.30.20:9001" timeout_ms: 5000 # 内网服务白名单（L3防护层） network_whitelist: - "http://10.20.30.10:8080" # LIS系统 - "http://10.20.30.11:5432" # PostgreSQL - "http://10.20.30.20:9000" # Tool Server # 熔断配置（L4防护层） circuit_breaker: failure_threshold: 5 # 连续5次失败则熔断 reset_timeout_ms: 60000 # 60秒后重置 fallback_action: "return_error" # 熔断后执行动作实操心得：
n_ctx参数极易填错。DeepSeek-Coder-33B原生支持32768上下文，但Q4_K_M量化后，实际可用约28000。若设为32768，推理时会静默截断，导致Agent“忘记”前面的指令。我们规定：所有n_ctx值必须是model_n_ctx * 0.85向下取整。这是血换来的经验。
4.4 启动与验证：五步走通第一个请求
启动不是./agent-server就完事。我们有一套标准化验证流程：
启动Agent并检查日志：
./agent-server --config config.yaml 2>&1 | tee agent.log
关键日志必须出现：[INFO] Loaded model from ./models/deepseek-coder-33b.Q4_K_M.gguf和[INFO] Whitelist loaded: 3 entries。若出现[WARN] Failed to load model，立即检查GGUF文件完整性（md5sum比对）。验证网络防护生效：
在App Server上执行：curl -v http://www.baidu.com 2>&1 | grep "Failed to connect"
必须返回该字符串。若返回* Connection timed out，说明iptables规则未生效，需检查iptables -L OUTPUT。调用健康检查接口：
curl http://localhost:8080/health
返回{"status":"ok","version":"1.2.0","uptime_sec":12}。若超时，检查server.port是否被占用，或SELinux是否阻止了端口绑定（sudo setsebool -P httpd_can_network_connect 1）。发送一个简单请求：
curl -X POST http://localhost:8080/invoke \ -H "Content-Type: application/json" \ -d '{"input": "请分析这份检验报告：ALT 120 U/L, AST 85 U/L", "tool": "lis_query"}'正确响应应为JSON，含
"action": "lis_query"和"result"字段。若返回{"error":"network_forbidden"}，检查lis_query是否在network_whitelist中。压力测试并发能力：
用wrk -t2 -c100 -d30s http://localhost:8080/invoke模拟100并发。观察：- CPU使用率应平稳在70%~85%，无剧烈抖动
- 内存增长≤50MB（Rust的确定性优势）
- 错误率<0.1%（主要来自LIS系统限流）
若错误率飙升，检查
circuit_breaker.failure_threshold是否过低，或tools.lis_query.timeout_ms是否小于LIS平均响应时间。
5. 常见问题与排查技巧实录
5.1 并发扛不住？先看这五个指标
“AI Agent怎么扛并发”是热搜词，但问题往往不在Agent本身。我们整理了内网环境下最常导致并发失败的五个指标，按排查优先级排序：
| 排查顺序 | 指标 | 检查命令 | 异常表现 | 解决方案 |
|---|---|---|---|---|
| 1 | 内网服务连接池耗尽 | ss -s | grep "TCP:"查看ESTAB连接数；netstat -an | grep :8080 | wc -l查看Agent端口连接数 | ESTAB连接数接近65535，或Agent端口连接数持续>1000 | 在config.yaml中增加tools.lis_query.pool_size: 200；LIS服务端调大max_connections |
| 2 | 磁盘IO瓶颈 | iostat -x 1 | grep sda查看%util和await | %util>95%，await>100ms | 将SQLite数据库文件移到SSD；或改用内存数据库（sqlite:///file::memory:?cache=shared） |
| 3 | gRPC子进程泄漏 | ps aux | grep python | grep ocr_tool | wc -l | 数量随时间线性增长，超过50个 | 在Rust代码中，Command::new("python").arg("ocr_tool.py")后，必须加.spawn()并保存Child句柄，定期kill()僵尸进程 |
| 4 | LLM推理显存溢出 | nvidia-smi | grep "python"查看GPU内存 | GPU内存使用率>95%，且agent-server进程显存占用>24GB | 降低llm.n_batch（默认512，改为256）；或换用更小模型（Qwen2-7B） |
| 5 | 时间不同步导致JWT失效 | chronyc tracking查看Last offset | Last offset>100ms | 配置内网NTP服务器，chronyc add server 10.20.30.1 iburst；Agent启动时执行chronyc makestep强制校准 |
独家技巧：我们写了一个
concurrency-debug.sh脚本，一键输出以上所有指标。客户运维只需执行它，就能拿到完整诊断报告。这比让他们逐条敲命令高效十倍。
5.2 Harness技能包离线部署：不是复制文件，而是重建信任链
“deepseek harness附带skill怎么部署到内网服务器”是高频问题。HARNESS本质是DeepSeek提供的技能模板（如web_search.py,code_interpreter.py），但它们默认依赖公网。离线部署的关键是技能重写，而非搬运。
以code_interpreter.py为例，原始代码会调用subprocess.run(["python", "-c", code])。这在内网有两大风险：1）Python版本不一致；2）无网络的pip install会失败。我们的改造步骤：
锁定Python环境：在Tool Server上，用
pyenv安装指定版本pyenv install 3.8.10，创建虚拟环境pyenv virtualenv 3.8.10 skill-env，激活后pip install numpy==1.21.6 pandas==1.3.5（版本严格锁定）。重写执行逻辑：不调用
subprocess，而是用exec()在当前Python进程执行。但exec()有安全风险，我们加沙箱：# skill_env.py import ast import numpy as np import pandas as pd def safe_exec(code: str) -> dict: # 1. AST静态检查：禁止import、open、os等危险节点 tree = ast.parse(code) for node in ast.walk(tree): if isinstance(node, ast.Import) or isinstance(node, ast.ImportFrom): raise SecurityError("Import not allowed") # 2. 执行并捕获stdout exec_globals = {"np": np, "pd": pd} exec(code, exec_globals) return {"result": str(exec_globals.get("result", "no result"))}编译为独立模块：用
pyinstaller --onefile --name code_interpreter skill_env.py生成code_interpreter二进制。App Server通过Command::new("./code_interpreter").arg("--code").arg(user_code)调用。
这样，一个技能包就从“依赖公网的Python脚本”，变成了“内网可验证的独立二进制”，彻底解决离线部署难题。
5.3 日志与监控：没有Prometheus，怎么知道Agent在想什么？
内网通常禁用Prometheus（认为其有暴露面）。我们用三日志一指标法：
三日志：
access.log：记录所有HTTP请求（时间、IP、路径、状态码、耗时）agent.log：记录Agent核心行为（LLM推理耗时、工具调用结果、状态机跳转）audit.log：记录所有安全事件（网络访问尝试、熔断触发、证书验证失败）
一指标：
我们用/proc/[pid]/stat中的utime（用户态CPU时间）和stime（内核态CPU时间）计算CPU使用率，每5秒写入metrics.csv：timestamp,cpu_percent,mem_kb,active_sessions,errors_5min 1717023456,42.3,324567,12,0运维人员用
tail -f metrics.csv即可实时监控，无需额外服务。
踩过的坑：早期我们用
psutil.cpu_percent()，结果发现它在某些内核版本下返回0。后来改用直接读/proc/[pid]/stat，数据100%可靠。工程实践就是不断用更底层的方式，换取确定性。
6. 最后的实战提醒：内网不是技术试验田
写到这里，我想说点掏心窝的话。过去三年，我见过太多团队把隔离内网当成“技术练兵场”，觉得“反正没外网，随便折腾”。结果呢？一个未经充分测试的Agent上线后，把医院HIS系统的订单状态批量改成“已取消”，因为它的order_cancel工具逻辑有缺陷；或者把电网调度指令中的“升压”误判为“降压”，差点引发区域性停电。
隔离内网的AI Agent，首要属性是“可靠”，其次才是“智能”。它不是展示技术的玩具，而是承载着真实业务责任的生产系统。所以，我坚持三个铁律：
铁律一：所有变更必须经过“双盲测试”。即，新版本Agent和旧版本Agent，用同一组1000条历史工单并行运行，输出结果必须100%一致，才能上线。不接受“99.9%相似”的说法。
铁律二：永远保留“人工接管开关”。在
config.yaml中设置manual_override: true，当Agent连续3次触发熔断，自动切换到human_in_the_loop模式：所有请求返回{"status":"waiting_for_approval", "request_id":"REQ-2024-001"}，由管理员在Web界面点击“批准”或“拒绝”。铁律三：文档比代码重要十倍。我们交付的文档，不是API手册，而是《故障树手册》：列出所有可能故障（如“OCR失败”），每个故障下列出：现象、3个最快检查项、2个临时解决方案、1个根治方案。客户运维照着手册，5分钟内就能定位80%的问题。
AI Agent在隔离内网的落地，不是一场技术秀，而是一次严谨的工程交付。它考验的不是你调参多快，而是你对边界条件的理解有多深，对失败模式的预判有多准，对客户业务敬畏有多真。当你把Agent放进那个“没网的保险柜”时，你放进去的不仅是一段代码，更是一份沉甸甸的承诺。