展示 LLM 工具数据传输的中间人代理

展示 LLM 工具数据传输的中间人代理

基本信息

• 作者: jmuncor
• 评分: 129
• 评论数: 56
• 链接: https://github.com/jmuncor/sherlock
• HN 讨论: https://news.ycombinator.com/item?id=46799898

导语

大语言模型（LLM）应用在提供便利的同时，其数据交互过程往往是一个“黑盒”，用户难以知晓工具究竟发送了哪些信息。本文介绍一款中间人代理工具，旨在帮助开发者和隐私敏感用户直接监控并分析这些 API 请求的原始内容。通过阅读，你将了解如何利用该工具捕获流量，从而更清晰地掌握本地数据与云端模型交互的具体细节。

摘要

内容总结：一个用于监控LLM工具通信流量的Mitm代理工具

一、 项目概述

这是一个名为“Show HN”的开源项目，本质上是一个中间人（MitM）代理工具，旨在帮助用户透明地查看本地大语言模型（LLM）工具（如代码编辑器插件、桌面应用等）与远程API（如OpenAI API）之间发送的具体数据内容。

二、 核心功能

1. 流量拦截与解密：通过在本地运行代理服务器，拦截并解密HTTPS流量，将原本加密的JSON请求和响应转化为人类可读的格式。
2. 数据审计：让用户能够直观地检查工具发送了哪些提示词、元数据以及系统参数，验证是否存在隐私泄露风险或未经授权的数据上传。

三、 典型使用场景

1. 隐私安全检查：确认应用是否上传了敏感代码、个人数据或凭证信息。
2. 调试与分析：开发者可分析工具的请求结构、参数配置及错误原因，优化集成效果。
3. 行为透明化：了解闭源LLM工具的实际运行逻辑，避免“黑盒”操作风险。

四、 技术实现原理

• 基于Python开发，使用标准HTTP代理协议。
• 支持自定义端口和证书配置（需本地信任CA证书以解密TLS流量）。
• 兼容主流LLM API端点（如OpenAI、Anthropic等）。

五、 应用价值

该工具填补了LLM工具生态中的透明度空白，为用户提供了低成本的数据监控能力，尤其适合开发者、安全研究员及隐私敏感用户。通过“可见即信任”的设计，强化了用户对AI工具的控制权。

评论

一、 核心观点与支撑逻辑

中心观点： 该文章介绍了一个用于拦截和分析大语言模型（LLM）API流量的中间人代理工具，其核心价值在于打破现有AI应用的“黑盒”状态，为开发者和安全研究人员提供了一种验证数据隐私、调试Prompt及审计模型行为的有效手段。

支撑理由（事实陈述/作者观点）：

1. 填补了LLM应用调试的盲区（事实陈述）： 目前市面上许多封装好的LLM工具（如桌面客户端、浏览器插件）在发送请求时进行了混淆或封装，开发者无法直接看到发送给OpenAI、Anthropic等API的确切JSON Payload。该工具通过MitM技术解密HTTPS流量，还原了真实的System Prompt和User Input。
2. 提供了安全与合规的审计能力（行业观点）： 在企业级应用中，数据泄露是最大风险之一。该工具允许安全团队直观地检查工具是否在未经授权的情况下上传了敏感数据（如代码库、用户PII），或者是否在System Prompt中植入了恶意的持久指令。
3. 具备极高的技术可扩展性与教学价值（你的推断）： 作为一个代理工具，它不仅可以“看”，还可以“改”。这为Prompt Injection攻击测试、自动化测试以及LLM行为分析提供了一个标准的中间层接口，是理解LLM工程化运作的优秀教学案例。

反例/边界条件（批判性思考）：

1. 对抗性防御机制的失效（技术局限）： 随着LLM服务商开始推行端到端加密（E2EE）或客户端直接密钥加密（如OpenAI部分官方客户端的做法），传统的MitM代理将无法解密流量，除非能对目标应用进行逆向工程并注入自定义证书，这在法律和技术上都有极高门槛。
2. 环境依赖性与部署成本（实际障碍）： 配置MitM代理需要修改操作系统或浏览器的信任证书，对于非技术背景的产品经理或高管来说，操作过于繁琐。此外，许多Electron应用有严格的证书校验机制（如Certificate Pinning），导致该工具无法直接生效。

二、 多维深度评价

1. 内容深度与严谨性： 文章（指代Show HN的帖子及关联项目）在技术实现上保持了极客风格的严谨性。它利用了经典的代理技术解决现代问题。然而，从深度上看，如果仅停留在“展示流量”层面，略显单薄。更深层次的价值在于分析这些流量背后的逻辑：例如，通过观察不同工具对Prompt的改写，可以推断出各厂商在“提示词工程”上的隐形优化策略。

2. 实用价值： 对LLM应用开发者而言，这是必装工具。它解决了“我的Prompt为什么在本地好用，封装进工具就变傻”的调试难题。通过对比原始输入和实际API请求，可以清晰地看到工具是否在背后篡改了上下文长度或添加了多余的噪音。

3. 创新性： 将经典的MitM代理应用于LLM生态并非全新概念（如已有mitmproxy），但将其专门针对LLM的JSON Schema进行格式化高亮和解析，属于微创新。它降低了分析LLM流量的门槛，将通用的黑客工具垂直化为AI领域的专用显微镜。

4. 行业影响： 这类工具的普及可能会迫使LLM工具开发商更加注重透明度。如果用户发现某个标榜“隐私”的工具实际上发送了大量元数据，将引发严重的信任危机。因此，它是社区监督商业软件的重要武器。

5. 争议点： 隐私与伦理的悖论。 MitM代理本身具有双重性：用于防御时它是审计工具，用于攻击时它是窃取API Key或中间人攻击的利器。此外，拦截流量可能涉及违反某些软件的服务条款，尤其是在绕过客户端安全校验时。

三、 实际应用建议与验证方式

应用建议：

• 建立“Prompt基准线”： 使用该工具捕获你常用工具在标准任务下的API请求，保存为基准。当工具更新版本或行为异常时，重新捕获对比，防止供应商静默修改Prompt逻辑。
• 成本分析： 统计不同工具对Token的计费点。有些工具可能会在内部多次调用LLM进行优化，通过代理可以精确看到每一次调用的Token消耗，从而评估成本合理性。

可验证的检查方式：

1. System Prompt 提取测试（指标）：

   • 操作： 使用该代理拦截一个知名的AI写作助手。
   • 观察窗口： 查看返回的JSON中 system 字段。
   • 验证： 是否能提取出该助手隐藏的“人设”指令？如果成功，说明该工具能有效逆向工程对手的Prompt策略。

2. 数据泄露审计（实验）：

   • 操作： 在本地创建一个包含敏感关键字（如API_KEY=123）的文件，并让被测工具总结该文件内容。
   • 观察窗口： 在代理的请求体中搜索该关键字。
   • 验证： 如果请求体中包含该关键字，说明工具将本地数据上传到了云端服务器，而非仅本地处理，这直接证明了隐私风险。

3. Token 计数精度验证（指标）：

   • 操作： 发送一段固定长度的文本，记录代理显示的Request Token数。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 示例1：基础HTTP代理服务器
from http.server import BaseHTTPRequestHandler, HTTPServer
import socketserver

class ProxyHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        # 打印请求详情
        print(f"收到请求: {self.path}")
        print(f"请求头: {self.headers}")
        
        # 转发请求到目标服务器
        self.send_response(200)
        self.send_header('Content-type', 'text/html')
        self.end_headers()
        self.wfile.write(b"Proxy response")

def run_proxy(port=8080):
    with HTTPServer(('', port), ProxyHandler) as httpd:
        print(f"代理服务器运行在端口 {port}")
        httpd.serve_forever()

# 说明: 这个示例展示了一个最简单的HTTP代理服务器，可以拦截并打印所有通过它的HTTP请求，适合用于调试网络请求。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# 示例2：HTTPS流量解密代理
from mitmproxy import http
from mitmproxy.tools.main import mitmdump

class InterceptLLM:
    def request(self, flow: http.HTTPFlow) -> None:
        # 拦截并打印请求内容
        print(f"\n[请求] {flow.request.method} {flow.request.pretty_url}")
        print(f"请求头: {flow.request.headers}")
        if flow.request.content:
            print(f"请求体: {flow.request.content.decode('utf-8', errors='replace')}")
    
    def response(self, flow: http.HTTPFlow) -> None:
        # 拦截并打印响应内容
        print(f"\n[响应] {flow.response.status_code}")
        print(f"响应头: {flow.response.headers}")
        if flow.response.content:
            print(f"响应体: {flow.response.content.decode('utf-8', errors='replace')}")

if __name__ == "__main__":
    # 启动mitmproxy，监听8080端口
    mitmdump(["-p", "8080", "-s", __file__])

# 说明: 这个示例使用mitmproxy库创建了一个能够解密HTTPS流量的代理服务器，专门用于拦截和查看LLM工具的API请求和响应。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# 示例3：OpenAI API请求拦截器
from flask import Flask, request, jsonify
import requests

app = Flask(__name__)

@app.route('/v1/chat/completions', methods=['POST'])
def intercept_openai():
    # 获取原始请求数据
    data = request.get_json()
    headers = dict(request.headers)
    
    # 打印请求详情
    print("\n=== OpenAI API 请求 ===")
    print(f"请求头: {headers}")
    print(f"请求体: {data}")
    
    # 转发请求到真正的OpenAI API
    response = requests.post(
        "https://api.openai.com/v1/chat/completions",
        json=data,
        headers=headers
    )
    
    # 打印响应详情
    print("\n=== OpenAI API 响应 ===")
    print(f"状态码: {response.status_code}")
    print(f"响应体: {response.json()}")
    
    return jsonify(response.json())

if __name__ == '__main__':
    app.run(port=8080)

# 说明: 这个示例创建了一个专门拦截OpenAI API请求的代理服务器，可以查看LLM工具发送给OpenAI的实际请求内容和收到的响应。

案例研究

1：某金融科技公司智能客服系统调试

1：某金融科技公司智能客服系统调试

背景: 该公司正在开发基于大语言模型（LLM）的智能客服系统，集成了第三方商业 API（如 OpenAI GPT-4）。系统通过 Prompt Engineering（提示词工程）注入了数千字的行业知识库上下文，以确保回答的准确性。

问题: 在测试阶段，开发团队发现 API 账单的 Token 消耗量远超预期，且偶尔会出现模型回答与注入的上下文无关的情况。由于代码逻辑复杂，开发人员无法确定是 Prompt 构建逻辑出现了重复注入，还是客户端在发送请求前被污染了数据。

解决方案: 安全团队部署了该 MitM（中间人）代理工具，将其配置在测试环境的出口网关上。通过解密 HTTPS 流量，团队完整地捕获了发送给 LLM 提供商的原始 JSON 请求体。

效果: 通过直接查看发送的真实 Payload，团队迅速定位了两个严重问题：一是上下文加载逻辑存在 Bug，导致同一段落被重复发送了 3 次，导致成本翻倍；二是某些特殊字符在传输过程中未正确转义，导致 Prompt 结构混乱。修复后，API 调用成本降低了约 60%，且回答准确性显著提升。

2：企业内部 AI 助手数据隐私合规审计

2：企业内部 AI 助手数据隐私合规审计

背景: 一家大型跨国企业为其员工部署了基于 LLM 的内部文档查询助手。该工具会自动检索内部 Wiki 并将相关片段发送给云端 LLM 进行总结。由于涉及公司机密，合规部门要求严格审查发送给外部 API 的具体数据内容。

问题: 开发团队虽然编写了代码来过滤敏感信息（如薪资、API Key），但合规部门需要验证这些过滤机制是否在所有边界情况下（如复杂嵌套的 JSON 数据或异常输入）依然有效，且不能仅依赖代码审查。

解决方案: 审计团队利用该 MitM 代理工具，模拟了各种包含敏感标签的测试用例。工具充当了“透明代理”，实时记录了所有流出内网的 HTTP/HTTPS 请求，让审计人员可以直接“看到”发送给 LLM 云端的实际内容，而无需查看复杂的后端日志。

效果: 审计过程中，团队发现了一个边界情况漏洞：当文档中包含特定格式的混淆代码时，正则过滤器会失效，导致少量敏感凭证被发送到了外部模型。利用该工具的实时抓包功能，团队在上线前成功修补了这一漏洞，避免了严重的数据泄露风险。

3：开源 IDE 插件开发者的逆向工程调试

3：开源 IDE 插件开发者的逆向工程调试

背景: 一位独立开发者正在编写一款 VS Code 插件，旨在增强现有 AI 编程助手的功能。为了实现更好的兼容性，他需要理解主流 AI 编程工具（如 Copilot 或 Cursor）在请求代码补全时使用的具体 Prompt 模板和参数设置。

问题: 这些商业工具的客户端代码通常是混淆或加密的，无法直接通过阅读源码来了解它们是如何构建请求的（例如使用了什么 System Prompt 或 Temperature 参数）。

解决方案: 开发者配置了该 MitM 代理工具，将其设置为系统代理并安装了信任证书。当他使用这些 AI 工具编写代码时，代理工具自动拦截并展示了所有发往 LLM 服务器的明文请求和响应。

效果: 他成功解析出了对方使用的 System Prompt 结构和特定的 Stop Sequence 参数。基于这些信息，他优化了自己的插件，使其生成的代码风格与主流工具高度一致，并成功复现了一个高级功能，大大提升了插件的兼容度和用户体验。

最佳实践

最佳实践指南

实践 1：建立完整的流量审计日志

说明: LLM 应用通常通过 API 发送敏感数据。仅仅在屏幕上查看流量是不够的，必须建立持久化的日志记录机制。这不仅有助于调试，还能在发生数据泄露时进行事后分析。MitM 代理应配置为自动记录所有请求和响应的元数据（时间戳、目标主机、内容大小）以及可选的负载数据。

实施步骤:

1. 修改 MitM 代理脚本，启用日志记录模块（如 Python 的 logging 库）。
2. 将捕获的 JSON 负载以结构化格式（如 JSON Lines）保存到本地文件或安全的日志聚合服务。
3. 配置日志轮转策略，防止磁盘空间被占满。

注意事项:

• 确保日志文件本身具有严格的权限设置，防止被其他进程读取。
• 如果日志包含敏感信息，必须考虑对日志进行加密存储或脱敏处理。

实践 2：严格实施敏感数据脱敏

说明: 在开发或测试环境中，LLM 工具可能会意外发送 PII（个人身份信息）或 API 密钥。直接在控制台或日志中明文显示这些数据是巨大的安全风险。最佳实践是在 MitM 代理层面配置过滤器，自动检测并掩盖敏感字段。

实施步骤:

1. 定义敏感关键词列表（如 “api_key”, “password”, “credit_card”, “ssn”）。
2. 在代理的响应处理逻辑中，编写中间件函数，扫描 JSON 负载。
3. 使用正则表达式或 JSON 路径替换，将敏感值替换为 [REDACTED] 或哈希值。

注意事项:

• 脱敏逻辑不应破坏 JSON 结构，以免导致下游解析错误。
• 确保脱敏规则符合所在地区的数据保护法规（如 GDPR）。

实践 3：验证 TLS 证书配置与信任链

说明: MitM 代理的核心原理是拦截 HTTPS 流量，这通常涉及自签名证书。如果客户端（LLM 工具）验证服务器证书，代理将会导致连接失败。为了确保代理既能工作又能模拟真实环境，必须正确管理证书信任。

实施步骤:

1. 生成 MitM 代理的根证书（CA）。
2. 在运行 LLM 工具的操作系统或容器环境中，将该根证书安装到“受信任的根证书颁发机构”存储区。
3. 在代理启动脚本中，确保使用该 CA 动态为每个目标域名生成证书。

注意事项:

• 不要在生产环境或涉及真实金融交易的系统中使用测试 CA 证书。
• 定期轮换 MitM 代理的 CA 证书，模拟证书过期的场景以测试客户端的韧性。

实践 4：精确的请求与响应断言

说明: 仅仅“看到”数据是不够的，自动化测试需要验证数据的正确性。利用 MitM 代理，可以编写断言来检查 LLM 工具发送的参数是否符合预期（例如，检查 temperature 参数是否在 0 到 1 之间，或是否发送了过长的上下文）。

实施步骤:

1. 在代理流程中挂载“检查点”脚本。
2. 针对特定的 API 端点（如 /v1/chat/completions）编写验证逻辑。
3. 如果请求或响应不符合预定义的规则（如 token 数量超过限制），抛出异常或标记该次请求。

注意事项:

• 保持断言逻辑的轻量化，避免显著增加网络延迟。
• 区分“阻断性错误”（如必须拦截的恶意请求）和“警告性信息”（如参数非最优）。

实践 5：模拟网络故障与 API 异常

说明: LLM 应用需要具备处理网络不稳定或上游服务错误的能力。MitM 代理不仅是被动的观察者，也是主动的故障注入器。通过代理故意返回 500 错误、超时或损坏的 JSON，可以测试客户端的错误处理逻辑。

实施步骤:

1. 在代理中配置特定的触发规则（例如：当请求包含 “test-fail” 标识时）。
2. 编写逻辑返回模拟的 HTTP 错误码（如 429 Rate Limit, 503 Service Unavailable）。
3. 测试 LLM 工具是否会自动重试、回退或优雅地崩溃。

注意事项:

• 确保故障注入机制有明确的开关，避免影响正常的开发流程。
• 记录故障注入的频率和类型，以便复现 Bug。

实践 6：监控 Token 使用量与成本分析

说明: LLM API 的调用成本与 Token 使用量直接相关。MitM 代理位于流量的关键路径上，是统计 Token 消耗和预估成本的最佳位置。通过实时解析请求和响应的 usage 字段，可以为开发者提供即时的成本反馈。

实施步骤:

1. 解

学习要点

• 该工具作为一个中间人代理，能够解密并展示本地大语言模型（LLM）应用发送给 API 的原始网络流量，解决了无法直接审查闭源工具行为的问题。
• 它揭示了本地工具在处理用户数据时的实际行为，验证其是否发送了超出预期的敏感信息或隐私数据。
• 通过拦截和分析请求，用户可以确认工具是否向模型提供商发送了不必要的系统提示词或内部指令。
• 该代理支持解密 HTTPS 流量，确保能够查看经过 SSL/TLS 加密的完整请求和响应内容。
• 它允许开发者或高级用户调试 AI 工具的异常行为，排查由于网络请求配置错误导致的问题。
• 这种方法突显了在使用非开源 AI 软件时进行独立技术审计的重要性，以防止数据泄露风险。

常见问题

1: 什么是 Man-in-the-Middle (MitM) 代理，为什么我需要用它来监控 LLM 工具？

1: 什么是 Man-in-the-Middle (MitM) 代理，为什么我需要用它来监控 LLM 工具？

A: Man-in-the-Middle (MitM) 代理是一种位于客户端（如您的 LLM 应用程序或开发环境）和服务器（如 OpenAI、Anthropic 或其他 LLM 提供商的 API）之间的拦截工具。

在 LLM 开发和调试的上下文中，您需要它的原因通常包括：

1. 数据隐私审查：确认您的工具在发送请求时，是否意外泄露了敏感的 PII（个人身份信息）、API 密钥或专有的提示词。
2. 调试与优化：查看原始的 JSON 请求和响应，分析 Token 计数是否准确，或者检查参数（如 temperature 或 max_tokens）是否按预期传递。
3. 网络排查：当 LLM API 调用失败或超时时，通过代理可以查看具体的 HTTP 状态码和错误详情，而不是仅仅依靠应用程序抛出的模糊错误信息。

2: 该工具是如何解密 HTTPS 流量的？这是否安全？

2: 该工具是如何解密 HTTPS 流量的？这是否安全？

A: LLM 提供商的 API 通常通过 HTTPS 进行加密，直接查看只能看到乱码。该代理工具通过在您的本地机器上生成一个自签名证书 Authority (CA)，并将其安装为您系统的受信任根证书来工作。

当您配置代理后，工具会拦截发往 API 的 HTTPS 请求，向服务器建立连接（解密服务器的响应），然后使用您的本地 CA 重新签名证书，向您的应用程序建立加密连接。

关于安全性：

• 本地使用是安全的：该代理通常设计为在本地运行（如 localhost），流量不会离开您的机器，因此不会将您的数据发送到第三方服务器。
• 不要在公共网络共享：您必须妥善保管生成的 CA 证书私钥。如果攻击者获得了您的 CA 私钥，他们理论上可以解密您的流量。
• 仅用于调试：建议仅在开发和调试阶段开启代理，在生产环境中应移除代理配置以减少中间环节并提高性能。

3: 我该如何配置我的应用程序或环境以使用此代理？

3: 我该如何配置我的应用程序或环境以使用此代理？

A: 配置方法取决于您使用的编程语言或工具。大多数 HTTP 客户端库都支持通过环境变量设置代理。通常，您需要设置以下环境变量（假设代理运行在本地 8080 端口）：

• HTTP_PROXY=http://127.0.0.1:8080
• HTTPS_PROXY=http://127.0.0.1:8080

具体场景示例：

• Python (Requests/OpenAI SDK): 在运行脚本前导出环境变量，或在代码中设置 os.environ['HTTPS_PROXY']。
• Node.js (Axios/Fetch): 使用 https-proxy-agent 包或设置全局 https_proxy 环境变量。
• cURL: 添加 -x http://127.0.0.1:8080 参数。
• 浏览器插件: 如果是 Web 端工具，可以在浏览器代理设置中配置指向该代理。

配置完成后，所有通过这些客户端发出的请求都会经过代理并被记录下来。

4: 这个代理能看到所有发送的数据吗？包括文件上传和流式响应？

4: 这个代理能看到所有发送的数据吗？包括文件上传和流式响应？

A: 是的，只要数据是通过 HTTP(S) 协议发送的，代理通常都能完整记录。

• 请求体：您可以看到完整的 JSON Payload，包括 system、user 和 assistant 的消息内容，以及函数调用参数。
• 文件上传：如果您正在使用 Whisper（语音转文字）或 Vision（图像分析）功能，代理会显示 Base64 编码的数据或二进制文件内容（取决于工具的展示方式，Base64 更常见）。
• 流式响应：这是 LLM 代理的一个关键功能。对于 stream: true 的请求，代理会捕获一系列的 data: {} 块。好的代理工具会将这些块重新组合或以可读的格式展示，让您看到生成过程的完整日志，而不仅仅是最终结果。

5: 使用代理会导致 API 调用失败或证书报错吗？

5: 使用代理会导致 API 调用失败或证书报错吗？

A: 是的，这是最常见的问题，通常表现为 SSL: CERTIFICATE_VERIFY_FAILED 或类似的错误。

原因与解决方法： 这是因为您的应用程序（或其底层的 HTTP 库，如 Python 的 certifi 或 Node 的 https 模块）不信任代理生成的自签名证书。

解决方法：

1. 禁用 SSL 验证（不推荐用于生产，但适合快速调试）：在代码中设置环境变量 NODE_TLS_REJECT_UNAUTHORIZED=0 (Node.js) 或者在 Python requests 中设置 verify=False。
2. 安装 CA 证书（推荐）：该工具通常会生成一个证书文件（例如 .pem 或 .crt）。您需要将此证书添加到操作系统的受信任根

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 许多现代 LLM 应用（如桌面客户端或 IDE 插件）会忽略系统的 HTTP/HTTPS 代理环境变量。请尝试配置一个本地代理监听器（如使用 Mitmproxy），并找出强制特定应用程序将流量路由 through 该代理的方法。

提示**: 除了在代码中设置 HTTP_PROXY 之外，你还可以尝试修改操作系统的网络设置，或者使用像 proxychains 这样的工具来强制 TCP 连接通过代理。对于某些应用，可能需要将其证书安装到操作系统的“受信任的根证书颁发机构”存储中。

引用

• 原文链接: https://github.com/jmuncor/sherlock
• HN 讨论: https://news.ycombinator.com/item?id=46799898

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

• 分类： 安全 / 开发工具
• 标签： LLM / 中间人攻击 / 代理 / 流量分析 / 隐私保护 / 调试工具 / HTTPS / API监控
• 场景： 大语言模型

相关文章

• Show HN：一款用于监控 LLM 工具数据传输的中间人代理
• 🔥欧洲首创！网站审计神器捍卫数据主权🇪🇺
• 🤖解密Codex智能体闭环：AI如何自主进化？
• 🚀Claude Code重磅隐藏功能：Swarms颠覆编程体验！
• 深度解密Agent循环！🚀从Codex看AI Agent的核心架构与价值🔍 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。