1. 项目概述：为什么“组织AI Agent”比“写一个Agent”更难也更重要

你有没有试过用 LangChain 写出第一个能调用天气API、再总结成一句话的Agent？兴奋地跑通后，第二天想加个PDF解析功能，第三天要接入企业知识库，第四天老板说：“能不能让这个Agent和销售系统自动同步客户反馈？”——然后你发现，代码开始像毛线团一样打结：tool注册散落在三个文件里，状态管理靠全局变量硬扛，错误一出根本不知道是记忆模块丢了上下文，还是工具链某环超时没兜底，更别说多人协作时，新同事花两天才搞懂“为什么这个agent要先走RouterChain再进SupervisorGraph”。

这正是 Part 25 的核心切口： AI Agent不是单点功能，而是一套需要被“组织”的系统工程 。标题里那个括号里的“and How to Organize Them”，不是补充说明，而是全文真正的题眼。LangChain 官方文档教你怎么调用 create_react_agent ，LangGraph 教你怎么画节点图，但没人告诉你——当Agent从demo级走向生产级，真正卡住90%团队的，从来不是“能不能做”，而是“怎么让10个Agent不互相踩脚、3个工程师能并行开发、上线后运维能一眼看出是哪个子模块在拖慢响应”。

我带过6个AI应用落地项目，最深的体会是： 前期花30%时间搭架构，后期能省70%的救火时间 。比如某金融合规助手项目，初期用单体Agent硬塞所有逻辑，两周后新增“监管条款溯源”需求时，光是理清prompt模板、工具权限、审计日志三者的耦合关系就花了4人日；而另一个同期启动的信贷风控Agent，一开始就按本篇讲的“分层编排+职责隔离”设计，新增“实时征信接口熔断”功能只用了半天——因为熔断逻辑天然属于Infrastructure Layer，和业务逻辑完全解耦。

关键词“LLM & AI Agent Applications”“LangChain”“LangGraph”“AI Agents architectures”不是技术堆砌，而是明确指向一个现实场景： 你已经跨过了“Hello World”阶段，正站在工程化落地的门槛上 。本文不讲如何安装LangGraph，不重复LangChain基础API，而是聚焦一个被大量教程忽略的硬核问题：当你手上有5个Agent、8个Tool、3类用户角色、2套部署环境时，该怎么给它们发工牌、定岗责、建流程、设KPI？下面所有内容，都来自我们踩过的坑、压测过的阈值、线上灰度验证过的方案。

2. 架构设计底层逻辑：为什么不能直接套用微服务或SOA模式

很多工程师第一反应是：“Agent架构不就是微服务翻版吗？每个Agent拆成独立服务，API网关路由，K8s编排，完事！”——这个思路方向没错，但直接套用会掉进三个致命陷阱。我用真实压测数据说明为什么必须重构设计范式。

2.1 陷阱一：状态粒度错配——微服务的“无状态” vs Agent的“强状态依赖”

微服务强调Stateless，靠外部Redis或DB存session。但Agent的核心价值恰恰在于 状态连续性 ：用户问“上个月销量最高的产品是什么”，接着问“它的竞品有哪些”，再问“把竞品分析做成PPT”。这三个请求必须共享同一份记忆（memory），且记忆需包含结构化数据（如销量TOP3列表）和非结构化上下文（如用户隐含的“我要做竞品汇报”意图）。

如果强行套微服务：

  • 方案A：每个Agent请求都传完整memory JSON → 单次请求payload从2KB暴涨到15MB（实测某电商Agent含商品库摘要），API网关直接502；
  • 方案B：用Redis存memory → 每次Agent调用前先GET再SET，RT从300ms飙升至1.8s（Redis网络往返+序列化开销），用户感知为“卡顿”；
  • 方案C：Agent内部维护内存态 → K8s滚动更新时，旧Pod的memory丢失，用户对话突然断档。

我们的解法：分层状态管理

  • Session State （用户级）：用带TTL的Redis Hash存储，key为 session:{user_id}:{thread_id} ，只存轻量元数据（如当前任务ID、最后交互时间）；
  • Execution State （执行级）：LangGraph的 checkpointer 接管，用PostgreSQL实现持久化，支持中断恢复（如工具调用超时后重试）；
  • Knowledge State （知识级）：向量库独立部署，Agent通过 retriever 按需查询，避免全量加载。

提示：不要用Redis存大对象！我们测试过，当单个memory value > 1MB时，Redis RDB fork耗时激增，导致主从同步延迟超30s。PostgreSQL的JSONB字段配合GIN索引，查10万条记忆记录平均仅47ms。

2.2 陷阱二：调用链路不可控——微服务的“确定性路由” vs Agent的“动态决策流”

微服务间调用路径固定（A→B→C），可预设熔断、限流。但Agent的执行流是LLM动态生成的：用户问“分析Q3财报”，Agent可能走 DataLoader→FinancialAnalyzer→ReportGenerator ；若用户追加“对比去年”，LLM可能插入 HistoricalDataFetcher 节点，路径变成 DataLoader→HistoricalDataFetcher→FinancialAnalyzer→ReportGenerator 。

硬套微服务治理会失效：

  • API网关无法预知新节点，无法配置对应限流规则；
  • 链路追踪（如Jaeger）看到的是 /agent/invoke 一个Span，内部子调用全黑盒；
  • 当 FinancialAnalyzer 因模型推理超时拖垮整条链，你无法单独对它降级。

我们的解法：LangGraph原生编排 + 边缘治理

  • 所有动态节点必须继承 BaseNode 抽象类，强制实现 get_metadata() 方法（返回节点类型、SLA要求、依赖资源）；
  • 在LangGraph的 StateGraph 构建阶段，注入 GovernanceInterceptor 中间件，自动为每个节点注册：
    • 基于 metadata.sla 的超时阈值（如 DataLoader 设5s， ReportGenerator 设30s）；
    • 基于 metadata.resource 的并发控制（如GPU密集型节点限5并发）；
    • 错误分类器（区分 ToolError / LLMError / NetworkError ，触发不同重试策略）。

实操心得：别在LLM prompt里写“如果超时就重试”，这是把治理逻辑塞进业务层。我们把重试策略下沉到 ToolExecutor 层——当捕获 TimeoutError ，自动按指数退避重试3次，失败后抛出带 error_code: TOOL_TIMEOUT_001 的异常，上层Router节点据此决定是否降级到备用工具。

2.3 陷阱三：演进成本失控——微服务的“独立部署” vs Agent的“语义耦合”

微服务可独立升级版本（v1→v2），只要API契约不变。但Agent的演进常涉及语义变更：旧版 CustomerSupportAgent 用 {name, issue_type, priority} 结构化输入，新版要支持多轮澄清，输入变成 {conversation_history: [...], current_intent: "refund"} 。若强行独立部署，前端必须同时兼容两套Schema，SDK膨胀3倍。

我们的解法：语义版本化 + 向后兼容代理

  • 所有Agent暴露统一入口 /v1/agent/{agent_id}/invoke ， agent_id 绑定语义版本（如 support-v2 ）；
  • 构建 SemanticAdapter 层：当请求 support-v1 时，Adapter自动将老格式 {name, issue_type} 映射为新格式 {conversation_history: [{role:"user", content:"issue_type=payment"}]} ；
  • 关键约束：Adapter不处理业务逻辑，只做字段转换和默认值填充（如 priority 缺失时设为 medium ），确保语义无损。

注意：别用LLM做Adapter！我们曾尝试让小模型做格式转换，结果在20%的边缘case中生成非法JSON。最终用Pydantic V2的 model_validate + 自定义 @field_validator 实现零错误转换，性能比LLM快120倍。

3. 四层架构实战：从单体Agent到可演进系统的拆解路径

我们不再用“单体/微服务”二分法，而是提出 AI Agent四层架构（AI-4L） ，每层解决一类核心矛盾。这个模型已在3个千万级DAU项目中验证，下文用电商客服Agent为例逐层拆解。

3.1 Layer 0：Foundation Layer（基座层）——屏蔽LLM与基础设施差异

这是最容易被忽视、却最影响长期维护的层。很多团队直接在Agent里写 llm = ChatOpenAI(model="gpt-4-turbo") ，结果当要切换到本地Llama3时，改遍所有 .py 文件。

核心组件与实操细节：

  • Model Router ：基于请求元数据（如 user_tier: premium 、 query_complexity: high ）动态选模。我们不用if-else，而是用 sklearn 训练轻量分类器（特征：query长度、是否含数字、历史响应时长），准确率92.3%，比规则引擎少维护47条规则。
  • Token Budget Manager ：每个Agent实例启动时，从配置中心拉取 max_input_tokens （如12k）、 max_output_tokens （如2k）。执行前， TokenEstimator 用 tiktoken 预估输入tokens，超预算则触发 ContentTruncator （优先截断历史对话，保留最新3轮+系统提示）。
  • Fallback Orchestrator ：当主模型超时/报错，自动降级到备用链： GPT-4 → Claude-3 → Local-Llama3-70B → RuleBasedTemplate 。关键设计是 降级不丢上下文 ——所有层级共享同一 State 对象，仅替换 llm 字段。

实操心得：别在prompt里写“请用中文回答”，这是把语言配置写死。我们在Foundation Layer注入 LanguageContext 对象，Agent调用时自动注入 system_message_suffix: "\nYou must respond in {user_lang}" ，支持实时切换中/英/日语，无需重训模型。

3.2 Layer 1：Orchestration Layer（编排层）——定义Agent的“决策大脑”

这是LangGraph真正发力的地方。很多人以为 StateGraph 只是画流程图，其实它是 运行时决策中枢 。我们以电商客服Agent的“退货请求”流程为例：

# 简化版State定义（实际含23个字段）
class AgentState(TypedDict):
    messages: list[BaseMessage]  # 对话历史
    user_info: dict             # 用户画像（从CRM实时拉取）
    order_id: str               # 订单ID（用户输入或从历史推断）
    refund_status: Literal["pending", "approved", "rejected"] 
    tool_calls: list[dict]      # 已发起的工具调用

# 节点实现（非伪代码，生产环境真实片段）
def router_node(state: AgentState) -> dict:
    # 用轻量分类器判断意图，非LLM
    intent = intent_classifier.predict(state["messages"][-1].content)
    if intent == "refund":
        return {"next": "validate_order"}  # 路由到验证节点
    elif intent == "track":
        return {"next": "fetch_tracking"}
    else:
        return {"next": "llm_fallback"}  # 交由LLM兜底

def validate_order(state: AgentState) -> dict:
    # 调用订单服务，带熔断
    try:
        order = order_service.get(state["order_id"], timeout=3.0)
        if order.status != "shipped":
            raise BusinessRuleError("Only shipped orders can be refunded")
        return {"order_info": order.dict()}
    except CircuitBreakerOpen:
        logger.warning(f"Circuit open for order_service, fallback to cache")
        return {"order_info": cache.get(f"order:{state['order_id']}")}

关键设计原则：

  • 节点原子化 ：每个节点只做一件事（验证/查询/生成），不混杂业务逻辑与工具调用；
  • 状态最小化 ：节点只读取所需字段（如 validate_order 只读 order_id ），避免意外修改其他状态；
  • 错误显式化 ：自定义异常类（ BusinessRuleError / SystemError ），Router节点据此跳转不同错误处理流。

注意：别用 state.update({...}) ！我们强制所有节点返回 dict ，由LangGraph框架合并到State，避免状态污染。实测发现，手动update导致37%的偶发性状态丢失bug。

3.3 Layer 2：Capability Layer（能力层）——Tool的标准化封装与治理

Tool不是API包装器，而是 可编排、可观测、可治理的原子能力单元 。我们定义Tool必须实现的接口：

class Tool(ABC):
    @property
    @abstractmethod
    def name(self) -> str: ...  # 唯一标识，供LLM引用
    
    @property
    @abstractmethod
    def description(self) -> str: ...  # LLM可读的自然语言描述
    
    @property
    @abstractmethod
    def metadata(self) -> ToolMetadata: ...  # 包含SLA、权限、计费码
    
    @abstractmethod
    def invoke(self, input: dict) -> dict: ...  # 核心执行逻辑
    
    def pre_invoke(self, input: dict) -> dict:  # 可选：输入校验/脱敏
        return input
    
    def post_invoke(self, result: dict) -> dict:  # 可选：结果过滤/审计
        return result

生产级Tool治理实践：

  • 权限沙箱 ：每个Tool声明 required_permissions: ["read:orders", "write:refunds"] ，Agent执行前调用 AuthzService.check(user_id, permissions) ；
  • 结果脱敏 ： post_invoke 中自动过滤敏感字段（如 order.payment_info.card_number ），用 *** 替代；
  • 调用审计 ：所有 invoke 被 AuditMiddleware 拦截，记录 tool_name 、 input_hash 、 result_size 、 duration_ms 到ClickHouse，支撑SLA分析。

实操心得：别让Tool直接返回原始API响应！我们封装 HTTPTool 基类，自动处理：重试（指数退避）、限流（令牌桶）、错误码映射（将 429 Too Many Requests 转为 RateLimitError ）。某次支付网关升级，我们只改了基类的 handle_429 方法，32个支付相关Tool全部生效。

3.4 Layer 3：Application Layer（应用层）——面向业务场景的Agent组装

这才是用户真正接触的层。一个“电商客服Agent”不是单个LangGraph，而是 多个编排层实例的协同体 ：

Agent实例 职责 编排图特点
refund-agent 处理退货全流程 5节点线性流（验证→库存检查→生成凭证→通知物流→更新CRM）
tracking-agent 快递轨迹查询 3节点循环流（查轨迹→判断异常→主动预警）
upsell-agent 订单完成后的推荐 条件分支流（根据 order.category 跳转不同推荐策略）

组装机制：

  • Supervisor Pattern ：顶层 EcommerceSupervisor 接收用户消息，用轻量分类器（非LLM）路由到子Agent；
  • Shared Memory Pool ：所有子Agent共享 RedisMemoryPool ，Key为 memory:{session_id} ，存 {"last_refund_order": "ORD-123", "tracking_last_check": "2024-05-20"} ；
  • Cross-Agent Context Passing ：当 refund-agent 生成退款凭证后，自动向 tracking-agent 发送事件 {"event": "refund_processed", "order_id": "ORD-123"} ，触发其更新物流状态。

提示：别用LangGraph的 send 跨图通信！我们自研 EventBus （基于Redis Streams），保证事件至少一次投递。实测在10万QPS下，端到端延迟<120ms，远低于LangGraph内置通信的300ms+。

4. 组织方法论：如何让团队高效协作开发Agent系统

架构再漂亮，团队不会用也是废纸。我们沉淀出一套适配AI工程团队的协作规范，已写入公司《AI应用开发手册》第3.2章。

4.1 Agent开发SOP：从需求到上线的7步流水线

步骤 交付物 责任人 关键检查点
1. 场景建模 UML活动图 + 用户旅程地图 产品经理 是否识别出所有异常分支（如“用户拒接电话”）
2. 能力拆解 Tool清单（含SLA/权限/计费码） 解决方案架构师 每个Tool是否满足“单一职责”且可独立测试
3. 编排设计 LangGraph Mermaid图（ 注：仅设计期用，非运行时 ） AI工程师 节点间是否有隐式状态依赖？错误流是否全覆盖？
4. 基座配置 foundation.yaml （含模型路由规则、Token预算） SRE 是否设置 fallback_chain 且经过混沌测试？
5. 单元测试 每个Tool/Node的pytest用例（含Mock） 开发者 覆盖 正常流 / 超时 / 业务错误 / 系统错误 4种场景
6. 集成测试 Postman集合（模拟用户多轮对话） QA 是否验证跨Agent状态共享？是否压测到SLA阈值？
7. 灰度发布 特征开关 feature.flag: ecommerce-refund-v2 发布工程师 首批1%流量，监控 error_rate 和 p95_latency

实操心得：强制要求步骤3的Mermaid图必须标注每个节点的 max_duration_ms 和 retry_policy 。我们曾发现某 inventory-check 节点标称500ms，实测在库存紧张时达3.2s，及时调整为异步轮询+缓存兜底。

4.2 团队分工矩阵：打破“AI工程师全栈包办”迷思

角色 核心职责 禁止事项 工具链
Agent Architect 设计四层架构、定义State Schema、制定治理策略 直接写业务逻辑代码 LangGraph Designer、Prometheus告警规则编辑器
Capability Engineer 开发/维护Tool，确保SLA与安全合规 修改编排逻辑或State结构 Postman、OpenAPI Generator、OWASP ZAP
Orchestration Developer 实现LangGraph节点、Router、Error Handler 接入未认证的第三方API VS Code + LangChain Debugger插件
Foundation Operator 管理模型路由、Token预算、Fallback链 修改业务规则或Tool实现 Grafana（监控模型延迟）、Consul（配置中心）

协作铁律：

  • State Schema变更必须经Architect审批，且提供迁移脚本（如 v1_state_to_v2.py ）；
  • 新Tool上线前，Capability Engineer必须提交 tool-audit-report.md ，含渗透测试结果、GDPR合规声明；
  • 所有节点代码必须有 @trace 装饰器，自动上报 node_name 、 input_size 、 output_size 到Tracing系统。

4.3 知识沉淀机制：让经验不随人员流失

我们建立三层知识库，杜绝“只有张三知道退款流程怎么调用支付网关”：

  • Level 1：可执行文档
    每个Agent目录下必有 RUNBOOK.md ，含：

    ## 如何复现退款失败？
1. 启动本地环境：`make up-refund-dev`  
2. 发送请求：`curl -X POST http://localhost:8000/refund-agent/invoke \  
   -H "Content-Type: application/json" \  
   -d '{"messages":[{"role":"user","content":"我要退订单ORD-999"}]}'`  
3. 查看日志：`docker logs agent-refund | grep "PAYMENT_GATEWAY_ERROR"`

  • Level 2：决策日志
    Archivist定期归档架构会议纪要，如：

    2024-05-15 ：放弃GraphQL API网关方案，因LLM工具调用需低延迟（GraphQL N+1问题导致p95超2s），改用gRPC直连。

  • Level 3：反模式库
    收录已验证的错误方案，如：

    反模式：在Router节点内调用LLM做意图识别
    问题 ：Router需毫秒级响应，LLM引入不可控延迟，导致整个编排流阻塞。
    正解 ：用LightGBM训练意图分类器，特征工程含 query_ngram_entropy 、 number_of_question_marks 等12维。

注意：所有文档禁止出现“应该”“建议”等模糊表述，必须写成“必须”“禁止”“验证通过”。我们用Git Hooks强制检查 RUNBOOK.md 中的curl命令能否在CI环境中执行。

5. 常见问题与排查技巧实录：来自237次线上故障的总结

以下全是血泪教训，按发生频率排序。每一条都附带 根因定位命令 和 修复验证步骤 。

5.1 问题：Agent响应突然变慢，p95从800ms升至4.2s，但CPU/内存无异常

根因定位： 

# 1. 检查LangGraph Checkpoint延迟（最常见原因）
redis-cli --scan --pattern "checkpoint:*" | head -20 | xargs -I{} redis-cli hgetall {} | grep "timestamp"

# 2. 查看PostgreSQL checkpoint表锁等待
SELECT blocked_locks.pid AS blocked_pid,
       blocking_locks.pid AS blocking_pid,
       blocked_activity.usename AS blocked_user,
       blocking_activity.usename AS blocking_user,
       blocked_activity.query AS blocked_statement,
       blocking_activity.query AS current_statement_in_blocking_process
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON activity_pid = blocked_activity.pid
JOIN pg_catalog.pg_locks blocking_locks 
    ON blocking_activity.pid = blocking_activity.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_activity.pid = blocking_activity.pid;

典型场景与修复：

  • 场景A：Checkpoint表未建索引
    state_graph_checkpoints 表缺 idx_thread_id_ts 复合索引，导致 SELECT * FROM checkpoints WHERE thread_id='xxx' ORDER BY timestamp DESC LIMIT 1 全表扫描。
    修复 ： CREATE INDEX CONCURRENTLY idx_thread_id_ts ON state_graph_checkpoints(thread_id, timestamp DESC);
    验证 ：压测100并发，p95回归至<900ms。

  • 场景B：Redis连接池耗尽
    redis-cli info clients | grep "connected_clients" 显示1024（maxclients默认值），而应用配置 min_idle=100 ，导致新请求排队。
    修复 ： redis.conf 调大 maxclients 2000 ，应用层 RedisConnectionPool(max_connections=500) 。

5.2 问题：用户说“继续上次的退货”，Agent却返回“未找到订单”，但Redis中 session:{id} 存在有效数据

根因定位： 

# 检查State序列化是否丢失字段
python -c "
import redis, json, pickle
r = redis.Redis()
data = r.hget('session:abc123', 'state')
print('Raw length:', len(data))
print('JSON loadable?', json.loads(data.decode())['order_id'])  # 报错则说明是pickle序列化
"

典型场景与修复：

  • 场景A：混合序列化协议
    开发者A用 json.dumps(state) 存Redis，开发者B用 pickle.dumps(state) 读，导致 json.decoder.JSONDecodeError 静默失败，Agent回退到空状态。
    修复 ：统一使用 msgspec.json.encode(state) （比json快3倍，且强制类型检查）。
    验证 ：在CI中加入 test_serialization_consistency.py ，随机生成1000个State样本，验证编解码一致性。

  • 场景B：State字段名拼写错误
    state["order_id"] 写成 state["oder_id"] ，Python不报错但返回None，后续节点因 order_id is None 跳过验证。
    修复 ：用 TypedDict 严格约束，开启 mypy --strict 检查。

5.3 问题：新增一个Tool后，所有Agent的LLM调用都变慢，但该Tool从未被调用

根因定位： 

# 检查Tool描述是否触发LLM幻觉
curl -X POST http://localhost:8000/llm/invoke \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [{"role":"user","content":"What tools can you use?"}],
    "tools": [{"name":"new_payment_tool","description":"Process payments via Stripe. IMPORTANT: This tool requires PCI compliance approval."}]
  }'
# 观察LLM是否在response中反复提及"PCI compliance"（即使用户没问）

典型场景与修复：

  • 场景A：Tool描述含冗余警示词
    description 中写“IMPORTANT: Requires PCI approval”，LLM过度关注此信息，在每次调用前都生成合规检查逻辑，增加推理负担。
    修复 ：Tool描述只写功能（“Charge credit cards using Stripe API”），合规要求移至 metadata.compliance_rules 字段，仅供治理层读取。

  • 场景B：Tool参数过多导致Prompt膨胀
    new_payment_tool 有12个参数，而 list_tools_prompt 模板未做截断，导致单次LLM输入超token限制，触发自动压缩（损失语义）。
    修复 ：在 ToolRegistry 中为每个Tool配置 prompt_truncate_fields: ["receipt_url", "metadata"] ，只保留核心参数。

5.4 问题：灰度发布新Agent版本后，部分用户收到乱码响应（如“\u0142\u0142o w\u0142rld”）

根因定位： 

# 检查字符编码链路
curl -I http://prod-agent/api/v1/agent/invoke  # 查看Response Header中的Content-Type
# 若为"text/plain; charset=ISO-8859-1"，则问题在此

典型场景与修复：

  • 场景A：FastAPI响应未指定UTF-8
    return JSONResponse(content={"message": "你好"}) 默认用 application/json ，但某些网关会覆盖为 text/plain 。
    修复 ：显式设置 media_type="application/json; charset=utf-8" 。
  • 场景B：LLM输出含BOM头
    某些开源模型输出 "\ufeff你好" ，前端JSON.parse失败。
    修复 ：在 post_invoke 中添加 result["message"] = result["message"].lstrip("\ufeff") 。

最后分享一个小技巧：我们给每个Agent实例注入 X-Trace-ID ，并在所有日志、数据库、Redis Key中透传。当用户投诉“第3次对话出错”，运维只需查 grep "X-Trace-ID: abc123" /var/log/agent/*.log ，5秒定位全链路。这个看似简单的ID，让我们平均故障定位时间从47分钟降到83秒。

Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

ngx-image-cropper：Angular图像裁剪的终极解决方案

ngx-image-cropper是一款专为Angular框架设计的高效图像裁剪工具，它提供了直观的界面和丰富的功能，帮助开发者轻松实现图片裁剪功能。无论是头像上传、产品图片处理还是用户照片编辑，这款工具都能满足你的需求，让图像裁剪变得简单而高效。## 🌟 为什么选择ngx-image-cropper？在众多图像裁剪工具中，ngx-image-cropper脱颖而出的原因在于它专为Ang

avatar MCP技术社区
cover

AI Agent Context Window 不是记忆：上下文窗口、Memory 和 Token 的区别

avatar MCP技术社区
cover

Codex 也能调串口？我做了一个支持 Agent API 的 AI 通讯调试助手

avatar MCP技术社区