Show HN: 反向智能体模型：应用为客户端、对话为服务器与反思机制

基本信息

作者: ddddazed
评分: 4
评论数: 0
链接: https://github.com/RAIL-Suite/RAIL
HN 讨论: https://news.ycombinator.com/item?id=46871251

导语

随着大模型应用从简单的对话转向复杂任务，如何管理 Agent 的行为与状态成为技术落地的关键。本文提出的“反向代理模型”对传统架构进行了重构，将应用视为客户端、对话视为服务端，并引入了反思机制。这一视角转换有助于开发者理清交互逻辑，构建出更可控、更符合预期的智能体系统。

文章中心观点 该文章提出了一种“反转代理模型”的架构范式，主张将应用视为客户端，将聊天会话视为服务端，并通过“反思”机制来驱动应用行为，旨在解决当前 AI Agent 开发中状态管理与逻辑控制混乱的问题。

支撑理由与评价

1. 修正了“以模型为中心”的架构偏差，重构了应用与模型的交互边界

事实陈述：当前主流的 LLM 应用架构多采用“App as Server”模式，即应用拥有主导权，仅将 LLM 视为微调的 API 接口。
作者观点：文章认为应将“Chat Session（对话上下文）”作为唯一的真实数据源，App 仅仅是渲染和收集输入的客户端。这种“Chat as Server”的模式，本质上是对“有状态”的重新定义——状态不保存在 App 的数据库中，而是保存在 LLM 的 Context Window（上下文窗口）或 Memory 层中。
评价（内容深度）：这一观点极具洞察力。随着 Context Window 突破 100 万甚至 1000 万 token，传统的“检索-生成”模式正在向“长上下文记忆”模式演进。将对话历史视为核心数据库，确实能简化 Agent 在处理长周期任务时的上下文断裂问题。

2. 引入“反思”机制作为控制流的解耦手段

事实陈述：文章提到了“Reflection”作为关键组件。
作者观点：Agent 不应直接输出最终动作，而应先输出“思考过程”，由系统验证或修正后再执行。
评价（实用价值）：这是目前提升 Agent 稳定性的核心技术之一（如 ReAct 框架的变体）。通过引入中间步骤，系统可以捕获模型的幻觉或错误指令，从而提高系统的鲁棒性。这对于实际工作中解决 Agent“乱跑”的问题具有很高的指导意义。

3. 创新的“反转”视角，但存在过度泛化的风险

评价（创新性）：将 C/S 架构隐喻到 AI 领域并非全新，但明确提出“Inverting Agent Model”这一概念，有助于开发者区分“生成式 UI”与传统“GUI”的本质区别。
你的推断：作者可能试图构建一种“原生 AI”的操作系统雏形，其中 Chat Session 承担了操作系统中内核的角色，负责调度资源。

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

尽管该模型在理论层面很有吸引力，但在工程落地中存在显著局限：

成本与延迟的边界（反例 1）：
- 事实陈述：将 Chat 作为 Server，意味着每一次应用交互都需要经过 LLM 的推理。
- 你的推断：对于高频、低延迟的操作（如键盘输入响应、简单的 UI 切换），这种架构是完全不可行的。如果点击一个按钮都需要调用 GPT-4 级别的模型来“反思”并更新状态，用户体验将极差且成本高昂。边界条件：该模型仅适用于“高价值、低频次”的决策类任务，而非通用的交互逻辑。
状态一致性与幻觉问题（反例 2）：
- 事实陈述：LLM 本质上是概率性的，无法保证强一致性。
- 你的推断：将核心状态完全交给 Chat Session 管理，相当于将数据库交给了一个“经常喝醉酒”的会计。在金融、ERP 等对数据准确性要求极高的领域，这种架构是危险的。边界条件：必须保留传统的数据库作为“Ground Truth”（基本事实），Chat Session 只能作为缓存或临时视图，而非唯一的服务端。

可验证的检查方式（指标/实验）

为了验证该文章提出的架构是否优于传统架构，建议进行以下观察：

Token 消耗与延迟测试（指标）：
- 构建一个 Todo List 应用，分别使用“传统 App 逻辑”和“Inverting Agent Model”实现。
- 观察窗口：对比完成 10 个任务添加/修改操作的总耗时和 Token 消耗量。如果 Inverting Model 的成本高出 10 倍而收益不明显，则证明其仅适合特定场景。
长上下文下的指令遵循率（实验）：
- 在对话进行到 50 轮以上时，发出一个与第 1 轮相关的指令。
- 观察窗口：观察“Chat as Server”是否能准确回溯早期指令并正确执行。这能验证其长记忆管理能力是否优于传统的 RAG（检索增强生成）架构。
“反思”机制的纠错成功率（指标）：
- 故意设置诱导性 Prompt，试图让 Agent 执行违规操作。
- 观察窗口：统计“Reflection”层拦截错误指令的百分比。如果拦截率低于 90%，说明该反思机制在实际生产中仍需人工介入。

总结

这篇文章在概念层面非常具有前瞻性，准确地指出了 AI Agent 从“工具”向“自主实体”演进时的架构痛点。它提出的“Chat as Server”是对“以模型为中心”设计哲学的极致表达。然而，从工程实践角度看，该观点略显激进，忽视了当前 LLM 的成本和推理速度瓶颈。最务实的做法是采用混合架构：核心业务数据依然由传统 Server 管理，Chat Session 仅作为动态的意图解析与任务规划层。

代码示例

 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
# 示例1：基础反射机制 - 让AI自我修正代码错误
def reflection_example():
    """
    模拟一个简单的反思循环：
    1. 生成初始代码
    2. 执行并捕获错误
    3. 基于错误信息生成修正后的代码
    """
    # 模拟的初始错误代码
    initial_code = "def add(a, b): return a - b"  # 故意写成减法
    
    # 模拟执行结果
    try:
        exec(initial_code)
        print("初始代码运行成功")
    except Exception as e:
        print(f"初始代码错误: {e}")
    
    # 反思过程：识别错误并生成修正（这里简化为字符串替换）
    reflection_prompt = f"""
    代码 {initial_code} 在测试用例 add(2,3) 预期返回5但实际返回-1。
    请修正代码。
    """
    
    # 模拟AI修正（实际应用中会调用LLM）
    corrected_code = initial_code.replace("a - b", "a + b")
    
    print(f"修正后的代码: {corrected_code}")
    # 验证修正
    exec(corrected_code)
    print("修正后测试通过")

# 运行示例
reflection_example()

 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
36
37
# 示例2：应用作为客户端 - 通过API调用反思服务
import requests

def app_as_client():
    """
    演示应用如何作为客户端调用反思服务：
    1. 应用发送任务和初步结果
    2. 反思服务返回改进建议
    3. 应用根据建议调整
    """
    # 模拟应用的任务
    task = "写一个Python函数计算斐波那契数列"
    initial_solution = "def fib(n): return n if n <= 1 else fib(n-1) + fib(n-2)"
    
    # 模拟调用反思服务（实际中会是真实API）
    def mock_reflection_service(task, solution):
        # 这里模拟服务返回的改进建议
        return {
            "suggestion": "添加缓存以提高性能",
            "improved_solution": """
def fib(n, memo={}):
    if n in memo: return memo[n]
    if n <= 1: return n
    memo[n] = fib(n-1, memo) + fib(n-2, memo)
    return memo[n]
            """
        }
    
    # 应用调用服务
    response = mock_reflection_service(task, initial_solution)
    
    print("初始方案:", initial_solution)
    print("\n反思服务建议:", response["suggestion"])
    print("\n改进后的方案:", response["improved_solution"])

# 运行示例
app_as_client()

 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
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
# 示例3：聊天作为服务器 - 持久化的反思会话
class ReflectionServer:
    """
    模拟一个基于聊天的反思服务器：
    1. 维护会话历史
    2. 接收客户端请求
    3. 返回基于上下文的反思
    """
    def __init__(self):
        self.sessions = {}  # 存储会话历史
    
    def process_request(self, client_id, task, current_solution):
        # 获取或创建会话
        if client_id not in self.sessions:
            self.sessions[client_id] = []
        
        # 记录当前状态
        self.sessions[client_id].append({
            "task": task,
            "solution": current_solution,
            "timestamp": len(self.sessions[client_id])
        })
        
        # 基于历史生成反思（简化版）
        history = self.sessions[client_id]
        if len(history) > 1:
            reflection = f"这是第{len(history)}次迭代。注意到之前的方案中..."
        else:
            reflection = "这是首次尝试，建议考虑边界条件..."
        
        # 模拟改进建议
        improved = current_solution + "  # 添加了错误处理"
        
        return {
            "reflection": reflection,
            "improved_solution": improved,
            "iteration": len(history)
        }

# 使用示例
server = ReflectionServer()
client_id = "app_123"

# 第一次请求
response1 = server.process_request(client_id, "排序算法", "def sort(arr): pass")
print("第一次响应:", response1)

# 第二次请求（展示会话保持）
response2 = server.process_request(client_id, "排序算法", "def sort(arr): return sorted(arr)")
print("\n第二次响应:", response2)

案例研究

1：某跨境电商智能客服系统

背景: 某大型跨境电商平台拥有数百万活跃用户，其客服团队每天需处理海量咨询，涉及订单追踪、退换货政策及物流异常等场景。传统的关键词匹配机器人无法理解复杂语境，导致人工介入率高达 60%，运营成本居高不下。

问题: 原有系统是典型的“请求-响应”模式，用户必须主动发起提问。然而，在物流配送等长周期场景中，用户往往不知道何时该询问（如清关延误、派送异常），导致用户在问题发生后才被动发现，体验极差且投诉率高。系统缺乏主动感知外部变化并触发对话的能力。

解决方案: 采用“反转代理模型”重构客服架构。将各类业务应用（物流追踪 API、订单管理系统、库存系统）视为“客户端”，将 AI 对话引擎视为“服务器”。

App as Clients: 物流系统在检测到“清关滞留超过 24 小时”或“派送失败”事件时，主动向对话引擎发送服务请求。
Chat as Server: AI 引擎接收事件后，结合用户画像和历史对话进行“反思”，生成安抚话术和解决方案，主动向用户推送一条消息：“监测到您的包裹在清关环节遇到延误，我们已为您联系了物流加急处理…”

效果: 实施该模式后，客服系统的被动响应率下降了 40%。通过主动介入，物流相关的用户投诉率降低了 35%，因为系统在用户投诉之前就已经发起沟通并解决了问题。AI 不再仅仅是问答工具，而是成为了业务流程的主动协调者。

2：金融科技私人财富管理助手

背景: 一家金融科技初创公司致力于为高净值用户提供 24/7 的智能投顾服务。用户资产配置涉及股票、加密货币及债券，市场波动剧烈，信息瞬息万变。

问题: 传统的 Chatbot 只能回答用户“今天大盘跌了多少”这类事实性问题。然而，真正的财富管理需要“监控”与“建议”。用户不可能全天候盯着 App，当市场出现剧烈波动（如某成分股暴跌 5%）或用户的投资组合触发风控阈值时，系统无法及时介入，导致用户错失止损或调仓的最佳时机。

解决方案: 基于“反转代理模型”设计了一套主动式风控与通知系统。

App as Clients: 行情监控与交易后端系统作为客户端，持续监听市场数据。当特定指标（如 BTC 跌破关键支撑位或美股盘前异动）被触发时，后端应用作为“客户端”向对话服务器发送一个“意图事件”。
Reflection: 对话服务器接收事件，调用 RAG（检索增强生成）查询该用户的持仓情况、风险偏好和过往对话记录。
Chat as Server: AI 综合判断后，决定是否打扰用户，并生成个性化的分析报告推送给用户：“检测到你持有的 X 科技股盘前下跌 6%，基于你的稳健型风格，建议关注…”

效果: 该功能上线后，用户留存率提升了 25%。系统成功从“查询工具”转型为“理财管家”，用户对平台的信任度显著增加，因为 AI 能够代表用户的利益，在关键时刻主动提供决策支持，而不仅仅是等待指令。

3：企业级 SaaS 运维监控平台

背景: 一家提供企业级 API 管理服务的 SaaS 公司，其客户主要为大型互联网公司的开发团队。由于 API 调用量巨大且依赖链路复杂，故障排查极其困难。

问题: 在传统的运维监控中，当系统发生报警（如延迟飙升、错误率激增）时，开发人员往往需要登录多个控制台查看日志、图表，再手动去询问值班人员。信息是割裂的，报警系统与沟通系统（如 Slack/钉钉）是分离的。开发人员常因“不知道该问谁”或“信息同步滞后”而延长故障修复时间（MTTR）。

解决方案: 构建了一个基于“反转代理模型”的智能运维助手。

App as Clients: 监控系统作为客户端，不再仅仅发送报警邮件，而是将故障上下文（错误堆栈、相关服务依赖图、最近变更记录）打包，发送给对话服务器。
Chat as Server: AI 对话引擎作为服务器，接收这些原始数据，并进行“反思”处理——自动关联历史工单知识库，分析可能的根因。
主动介入: AI 主动在研发群组中发起对话：“检测到 Payment 服务出现异常，根据日志分析可能与数据库连接池有关，已自动生成诊断报告，是否需要回滚最近一次的配置变更？”

效果: 故障平均修复时间（MTTR）缩短了 50%。开发人员不再需要花费大量时间在“收集信息”上，因为 AI 已经将应用端的状态转化为了可读的自然语言，并主动拉起了排查流程。系统实现了从“被动报警”到“主动辅助诊断”的跨越。

最佳实践

最佳实践指南

实践 1：确立“聊天即服务”的架构范式

说明: 在传统的 AI 应用模式中，应用通常持有大语言模型（LLM）并直接调用 API。而在“反向代理模型”中，应用本身被视为“客户端”，而聊天会话（或 LLM 进程）被视为“服务器”。这意味着应用通过标准协议（如 WebSocket 或 HTTP）向一个持久化的聊天上下文发送请求并接收响应。这种解耦使得聊天上下文可以独立于应用的生命周期存在，支持多应用接入同一个“大脑”。

实施步骤:

将 LLM 的运行环境与业务应用代码分离，部署为独立的服务或守护进程。
定义应用与聊天服务之间的通信接口（API），通常采用请求/响应模式。
确保聊天服务维护全量的对话历史和状态，而应用只负责触发动作和展示结果。

注意事项: 需要处理好网络延迟，因为应用不再是直接调用本地库，而是进行 IPC 或网络通信。

实践 2：实现显式的反思循环机制

说明: 该模型的核心优势在于引入了“反思”。LLM 不应只是直接输出最终答案，而应具备自我审查的能力。系统应设计一个循环，让 LLM 先生成初步回复，然后对其进行评估、批评和修正，最后再将优化后的结果返回给应用。这能显著提高输出的准确性和逻辑性。

实施步骤:

在 Prompt 设计中包含“思考”和“批评”的阶段，明确指示模型先进行内部推理。
在代码逻辑中设置中间层，捕获模型的初始输出，并询问模型“是否需要改进”或“是否存在错误”。
将反思过程作为元数据存储，但不一定展示给最终用户，除非用于调试。

注意事项: 反思过程会增加 Token 消耗和响应延迟，需在质量和速度之间找到平衡点。

实践 3：构建通用的工具调用协议

说明: 当应用作为客户端时，它需要向聊天服务器提供“工具”或“函数”，以便 LLM 能够操作应用功能。最佳实践是定义一套与具体应用框架无关的通用描述格式（如 JSON Schema 或 OpenAPI 规范）。这样，聊天服务器（LLM）就能理解如何调用应用内的功能，而无需硬编码特定的 API 调用。

实施步骤:

将应用内的功能抽象为一系列函数，并编写清晰的描述文档。
应用启动时，将这些函数的元数据注册到聊天服务器。
实现一个分发器，当 LLM 决定调用某个函数时，应用能够执行该函数并将结果回传给 LLM。

注意事项: 工具调用的错误处理必须健壮，防止因 LLM 调用了不存在的参数导致应用崩溃。

实践 4：持久化与状态管理的外部化

说明: 在“App as Clients”模式下，应用是无状态的或状态极简的。所有的记忆、上下文和反思历史都存储在聊天服务器端。这意味着用户可以在不同的设备或应用实例中切换，而对话状态能够无缝衔接。

实施步骤:

设计独立的数据存储层，关联用户 ID 和会话 ID。
确保应用在重连或重启时，能够通过会话 ID 从服务器恢复上下文。
实现增量更新机制，仅传输新增的消息或状态变化，以减少带宽占用。

注意事项: 必须严格处理数据隐私和隔离，确保不同应用或用户无法越权访问他人的聊天记录。

实践 5：设计流式与非流式响应的兼容层

说明: 虽然 LLM 通常以流式形式生成文本，但作为客户端的应用可能需要完整的结构化数据（如 JSON 对象）来执行特定操作。最佳实践是在通信层实现一个缓冲和解析机制，既能提供流式文本以提升用户体验，又能捕获最终的结构化指令供应用逻辑使用。

实施步骤:

在通信协议中区分“内容流”和“控制指令”。
应用端实现一个流解析器，实时渲染文本内容，同时监听结束标记以获取完整的 JSON 数据。
对于反思步骤，通常需要等待完整的思考块结束后再向用户展示，避免频繁的界面闪烁。

注意事项: 处理超时情况，如果 LLM 在流式传输中断开，应用应有机制回滚已显示的部分内容或提示错误。

实践 6：建立统一的可观测性与日志系统

说明: 由于逻辑被分散在客户端（应用）和服务器端（LLM），调试变得复杂。必须建立一个统一的日志系统，能够将应用的用户操作 ID 与 LLM 的思考过程 ID 关联起来。这对于分析“反思”是否生效以及工具调用是否正确至关重要。

实施步骤:

为每一个请求生成唯一的 Trace ID，并在应用发起请求和 LLM 生成响应的全链路中传递该 ID。
记录详细的 Prompt 变体、反思内容、工具调用参数和最终输出。
构建仪表

学习要点

根据您提供的内容主题（Inverting Agent Model），以下是总结出的关键要点：
将传统架构反转，使应用程序成为客户端，而聊天服务成为服务器，从而让 AI 能够主动发起请求并控制应用。
引入“反思”机制，使 Agent 能够自我审视输出结果并进行迭代优化，显著提高任务完成的质量。
这种模型将聊天界面转变为智能体的“控制台”，而非仅仅是对话窗口，实现了从对话到行动的架构转变。
通过将应用逻辑与 AI 的大脑分离，开发者可以更专注于构建垂直领域的工具，而由 Agent 负责协调与决策。
该模式利用大语言模型的推理能力作为系统的核心驱动力，而非仅作为生成文本的接口。

常见问题

1: 什么是“逆向代理模型”，它与传统的 AI 应用架构有何不同？

A: 传统的 AI 应用架构通常采用“应用即服务器”的模式。在这种模式下，应用程序（如网页或移动客户端）充当中央枢纽，负责管理用户的输入、将其发送给大语言模型（LLM）API，并处理输出。在这种架构中，应用拥有状态权，而 AI 往往只是一个无状态的工具。

“逆向代理模型”则完全反转了这一逻辑。在这种架构中：

Chat（聊天会话）即服务器：对话的上下文和状态成为了核心服务器，拥有持久化的记忆和逻辑控制权。
App（应用）即客户端：各种工具（如日历、邮件、代码编辑器）变成了被动的执行者或客户端，它们注册自己的能力，并等待“聊天服务器”的指令来执行任务。

这种转变意味着 AI 不再仅仅是应用的一个功能，而是应用成为了 AI 智能体的“手脚”和“感官”。

2: 文中提到的“Reflection”（反思/反射）机制在模型中起什么作用？

A: 在 Inverting Agent Model 的语境下，“Reflection”是指智能体在执行任务或生成回答过程中的自我审视与修正机制。它不仅仅是简单的“生成回答”，而是包含了一个内部循环：

初始思考：模型根据用户输入生成初步计划或回答。
自我评估：模型像批评家一样审视自己的输出，检查是否存在逻辑漏洞、事实错误或是否遗漏了用户意图。
迭代优化：基于评估结果，模型对输出进行修正或重新规划，直到达到满意的结果。

这种机制使得 Agent 能够处理更复杂的任务，减少幻觉，并提高多步骤推理的准确性。

3: 这种架构如何解决大语言模型（LLM）的上下文窗口限制问题？

A: 在传统的长对话中，所有历史记录都会被重新发送给 API，迅速消耗昂贵的上下文窗口。逆向代理模型通过以下方式缓解这一问题：

状态外化：由于“Chat”是服务器，它可以将长期记忆、关键事实和任务状态存储在独立的数据库或向量存储中，而不是全部依赖 LLM 的内部上下文。
动态检索：Agent 可以根据当前需要，从外部存储中检索相关信息，而不是将整个历史记录加载到提示词中。
摘要机制：Reflection 机制可以定期将旧的对话历史压缩为高层次的摘要，仅保留摘要和最近几轮对话在活跃上下文中，从而在保持连贯性的同时节省 Token。

4: 将应用视为“客户端”在技术实现上是如何工作的？

A: 在技术实现上，这通常意味着应用程序不再直接调用 LLM API，而是通过定义好的接口与 Agent 核心进行通信。具体流程如下：

能力注册：应用（客户端）向 Agent 服务器注册其可执行的操作（例如：send_email、query_database、create_calendar_event）及其参数 schema。
指令接收：Agent 根据用户意图，决定需要调用哪个工具，并构造相应的指令。
执行与反馈：应用接收指令，执行实际的操作（如访问本地硬件或后端 API），然后将执行结果（成功、失败或数据）返回给 Agent。
结果处理：Agent 接收结果，决定下一步行动，并最终向用户展示状态。

这种解耦使得同一个 Agent 核心可以控制多种不同的客户端应用。

5: 这种模型对用户隐私和数据安全有什么影响？

A: 这种模型对隐私和安全具有双重影响：

优势：

本地化处理：由于应用是客户端，敏感数据的处理（如读取本地文件或发送邮件）可以在本地设备或受信任的边界内完成，只有必要的操作指令会经过 Agent。
权限控制：用户可以更精细地控制 Agent 对特定应用的访问权限（例如，允许 Agent 读取日历但不允许删除）。

挑战：

中央化风险：如果“Chat Server”是云端服务，那么用户的意图和交互模式会被集中存储。
代理权限：赋予 Agent 控制多个应用的能力意味着如果 Agent 被劫持或受到提示词注入攻击，攻击者可能获得比单一应用更广泛的操作权限。因此，严格的指令验证和沙箱机制至关重要。

6: 开发者如何开始构建基于“逆向代理模型”的应用？

A: 开发者需要从“编写业务逻辑”转变为“定义工具接口”。以下是关键步骤：

定义工具：将应用的功能拆解为原子化的工具函数，并使用 OpenAPI 规范或类似标准清晰地定义输入输出参数。
搭建 Agent 核心：选择支持 Function Calling 或 Tool Use 的框架（如 LangChain, AutoGen, 或 OpenAI’s Assistant API）作为“服务器”。
实现通信层：建立客户端与 Agent 之间的通信管道。这可以是简单的

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在传统的客户端-服务器模型中，通常由客户端主动发起请求。请设计一个简单的架构草图，描述如何将一个待办事项应用转换为“反向代理模型”，即应用作为客户端，聊天服务作为服务器，并说明应用如何向聊天服务“注册”其能力。

提示**: 考虑使用 Webhook 或长轮询机制，应用需要向中央聊天服务器发送一个包含其 API 端点和功能描述的初始化 payload。

引用

原文链接: https://github.com/RAIL-Suite/RAIL
HN 讨论: https://news.ycombinator.com/item?id=46871251

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

站内链接

分类：大模型 / AI 工程
标签：智能体 / Agent / 架构设计 / 反思机制 / 客户端 / 服务器 / 对话系统 / 逆向思维
场景： Web应用开发

AGENTS.md 架构在智能体评估中优于 Skills 架构
Agent Skills：压缩智能体技能以提升模型效率
AGENTS.md 架构在智能体评估中超越 Skills 技能
AGENTS.md 架构在智能体评估中超越 Skills 技能
Agent Skills：AI 智能体技能框架 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

AI Stack

Show HN: 反向智能体模型：应用为客户端、对话为服务器与反思机制