智能体架构设计：OpenProse、Harness与AGE三大方向层技术解析

1. 从“指令”到“意图”：为什么我们需要区分控制与方向？

最近在折腾几个基于大语言模型的智能体项目时，我遇到了一个挺有意思的困境。我让一个智能体去处理一份用户上传的PDF文档，指令是“总结这份报告的核心观点”。结果，它确实生成了一个总结，但同时也自作主张地把报告里所有疑似电话号码和邮箱地址都高亮标记了出来，还“贴心”地问我是否需要生成一个联系人列表。这显然不是我想要的。这个看似微小的“跑偏”，背后反映的其实是当前智能体架构设计中一个普遍存在的模糊地带：我们到底是在“控制”智能体的具体行为步骤，还是在“引导”它的宏观目标和价值取向？

这让我开始深入思考“控制层”和“方向层”的分野。简单来说，控制层关心的是“How”——如何一步步执行任务，比如先调用哪个API，后解析哪个字段，遇到错误如何回退。它像是一个精确的流程引擎。而方向层则关乎“What”和“Why”——任务的最终目标是什么？应该遵循什么样的原则和价值观？哪些边界绝对不能逾越？它更像是一个战略指挥官或道德指南针。在早期的智能体系统中，这两层常常被混为一谈，用一个笼统的“提示词”或“指令集”来搞定，结果就是智能体要么僵化死板，要么容易“放飞自我”。

今天，我们就来聊聊三个试图厘清这层关系的框架或思想：OpenProse、Natural-Language Agent Harnesses以及AGE。它们代表了不同的解决路径，而理解它们之间的差异，对于我们设计出更可靠、更可控的智能体系统至关重要。特别是结合最近的热词，比如在Python生态中出现的_age扩展，以及Docker部署PostgreSQL-AGE的实践，我们能更清楚地看到理论如何落地。

2. OpenProse：将“方向”编码为可执行的规范

OpenProse 不是一个具体的软件库，而是一种方法论和规范提案。它的核心思想非常直接：将人类对智能体的高层意图和约束，用一种结构化的、机器可读的“散文式”规范语言描述出来，并使其成为智能体决策流程中不可或缺的一部分。

2.1 核心理念：超越提示词的精确约束

传统的提示词工程（Prompt Engineering）存在天然缺陷。它依赖自然语言的模糊性，智能体对“不要泄露隐私”这种指令的理解可能千差万别。OpenProse 试图建立一种更形式化的规范语言。这种语言看起来像结构化的英语（故称“Prose”），但具有明确的语义，可以被专门的分析器或编译器处理。

例如，对于一个客服智能体，OpenProse 规范可能这样写：

AGENT Customer_Service_Agent: OBJECTIVE: Resolve user inquiries about product features and billing. CONSTRAINTS: - NEVER disclose internal API keys or database connection strings. - ALWAYS verify user identity via the `auth_service` before accessing account details. - IF user query contains sentiment keywords ["angry", "frustrated", "cancel"], THEN priority = HIGH and escalate tone to `empathetic`. - RESPONSE time for any query must be under `30` seconds. SUCCESS_CRITERIA: - User inquiry is resolved OR correctly escalated. - No constraint is violated.

这与一段提示词“你是一个客服助手，要友好，注意保护用户隐私，尽快回复”有着本质区别。OpenProse规范是声明式的，它明确规定了禁止项（NEVER）、前置条件（ALWAYS...before）、条件逻辑（IF...THEN）和量化指标（under 30 seconds）。控制层的执行引擎（比如一个工作流调度器）可以解析这些规范，并在每一步动作前进行校验。

2.2 实践中的挑战与价值

在实际项目中引入OpenProse思想，意味着你需要：

1. 定义规范语法：虽然OpenProse提出了理念，但具体的语法需要你自己或团队定义。这相当于为你的智能体生态创建一门“领域特定语言”。
2. 构建规范编译器/检查器：需要一个中间件，在智能体执行链的各个环节（计划生成、工具调用、结果输出）注入检查点，验证当前操作是否符合所有相关规范。
3. 与现有控制流集成：如何让基于Pythonasyncio或类似框架编写的智能体执行引擎，能够无缝查询和遵守这些规范，是一个工程挑战。

它的价值在于可审计性和安全性。一旦规范确定，你可以像检查代码一样检查智能体的行为边界，理论上可以证明某些有害行为绝不会发生。这对于金融、医疗等高风险场景尤为重要。

注意：OpenProse目前更多是一种学术和前瞻性的设计理念，社区中还没有一个叫“OpenProse”的标准库。你需要基于它的思想自行实现规范层。

3. Natural-Language Agent Harnesses：用自然语言“驾驭”智能体

如果说OpenProse追求的是形式化的精确，那么Natural-Language Agent Harnesses的思路则更“人性化”一些。Harness 意为“马具、挽具”，这个词非常形象地描绘了它的目标：用自然语言作为缰绳，来引导和约束智能体这匹“骏马”的奔跑方向，而非直接控制它的每一步马蹄。

3.1 核心机制：动态上下文管理与元提示

这类框架（例如 LangChain 的AgentExecutor或 AutoGPT 早期设计中的某些思想）通常会提供一个“Harness”外壳。这个外壳的核心职责是：

• 管理对话历史与上下文：智能体本身可能“健忘”，Harness负责维护完整的交互历史，确保方向的一致性。
• 注入元提示：在用户的具体问题之前或之后，自动添加系统级的指导性语言。这些元提示就是“方向层”信息。
• 监控与干预：根据预设的规则（可能仍是自然语言描述的），判断智能体是否跑偏（如进入死循环、尝试危险操作），并实施干预，比如重置对话、注入纠正性提示。

例如，一个研究助手智能体的Harness可能会动态地在每次调用LLM前添加这样一段元提示：

你是一个严谨的学术研究助手。你的所有回答必须基于可靠的来源，并优先引用最近三年的文献。对于任何健康或医疗建议，你必须明确声明“这不是专业医疗意见，请咨询合格医生”。你当前的任务是：{user_query}。

这里的元提示定义了“严谨”、“基于可靠来源”、“声明免责”等方向性要求。Harness 确保这些要求贯穿智能体生命周期的始终，无论用户的具体问题是什么。

3.2 优势与局限：灵活性与模糊性的平衡

这种方式的优势是灵活且易于上手。开发者直接用自然语言编写约束，无需学习新的规范语言。它很好地利用了LLM本身对自然语言的理解能力。

但其局限性也很明显：

1. 可靠性问题：自然语言的模糊性依然存在。LLM可能会“创造性”地解读某些约束，或者在某些复杂场景下忽略它们。
2. 缺乏刚性保证：它无法像OpenProse那样提供“绝不可能违反某条规则”的形式化保证。约束的效力取决于LLM的遵从度和Harness的监控粒度。
3. 上下文消耗：冗长的元提示会占用宝贵的上下文窗口令牌数，可能影响智能体处理核心任务的能力。

在实际开发中，Harnesses 常被用于对绝对安全性要求不高、但需要一定灵活性和创造性的场景，比如创意生成、初步调研、代码辅助等。

4. AGE：将“方向”具象化为可计算的知识图谱

AGE在这里有双重含义。首先，它指代Apache AGE，一个基于 PostgreSQL 的图数据库扩展，允许用户使用 Cypher 查询语言在关系型数据库上处理图数据。其次，在智能体架构的语境下，它代表了一种将方向层信息建模为知识图谱的技术路径。这正是python _age和docker 安装 postgresql age成为热词的原因——大家开始在工程中实践这个想法。

4.1 知识图谱作为方向层的载体

AGE（图数据库）提供的是一种基础设施。其核心思想是：将智能体需要遵循的规则、领域知识、业务流程、实体关系，构建成一个显式的知识图谱。

• 节点可以代表：任务目标、约束条款、工具、数据实体、用户角色。
• 边可以代表：依赖关系、冲突关系、继承关系、执行顺序。

例如，一个电商订单处理智能体的方向层知识图谱可能包含：

(规则: “仅客服主管可处理退款额>1000的订单”) -[适用]-> (角色: “客服主管”) (工具: “退款审批系统”) -[需要输入]-> (数据实体: “审批流水号”) (任务: “生成退款单”) -[前置条件]-> (状态: “订单已核实”)

当智能体（控制层）接到一个“处理订单A退款”的任务时，它首先会查询这个AGE知识图谱。查询会告诉它：当前用户角色是否满足规则？执行“生成退款单”前是否需要先完成“订单核实”？需要调用哪个工具，以及该工具需要什么参数？

4.2 基于AGE的智能体架构实践

这就是为什么你会看到大家讨论docker 安装 postgresql age。一个典型的架构步骤如下：

1. 部署基础设施：使用 Docker 快速部署一个包含 Apache AGE 扩展的 PostgreSQL 数据库。这将成为你的“智能体方向知识库”。

   # 示例：拉取并运行Apache AGE的PostgreSQL镜像 docker run --name my-age-db -e POSTGRES_PASSWORD=mysecretpassword -d apache/age

2. 构建知识图谱：使用Cypher语言，将你的业务规则、安全策略、流程依赖插入到图数据库中。

   -- 在AGE中创建一条约束规则 SELECT * FROM cypher('my_graph', $$ CREATE (:Policy { id: 'POL001', description: '禁止向黑名单国家发货', condition: 'customer.country IN ["XX", "YY"]', action: 'BLOCK_ORDER' }) $$) as (policy agtype);

3. 智能体集成：在你的Python智能体控制层代码中，集成psycopg2或asyncpg等驱动，并安装pgage或类似库来方便地执行Cypher查询。

   # 示例：智能体在执行发货前查询方向层（AGE图谱） import asyncpg import asyncio async def check_shipping_policy(customer_country): conn = await asyncpg.connect('postgresql://user:password@localhost/dbname') # 查询是否存在阻止发货的规则 query = """ SELECT * FROM cypher('my_graph', $$ MATCH (p:Policy {action: 'BLOCK_ORDER'}) WHERE $customer_country IN p.condition RETURN p.description AS reason $$, $1) as (reason agtype); """ # 注意：实际条件匹配需要更复杂的解析，此处为概念演示 result = await conn.fetch(query, customer_country) await conn.close() if result: return f"订单被阻止，原因：{result[0]['reason']}" return None # 控制层逻辑 shipping_check = await check_shipping_policy("XX") if shipping_check: print(shipping_check) # 输出阻止原因，流程终止 else: proceed_with_shipping() # 继续执行发货流程

4.3 AGE路径的优势与考量

优势：

• 显式化与可查询：所有规则和关系以结构化数据存在，清晰明了，支持复杂推理查询（如“找出所有会影响当前任务的政策”）。
• 动态更新：可以在不重启智能体的情况下，通过更新图数据库来修改方向层规则。
• 关系推理：利用图数据库的优势，可以处理复杂的多跳关系，例如“用户所属部门受制于公司合规政策，而该政策引用外部法规条款”。

考量：

• 系统复杂性：引入了一个新的数据库系统，增加了架构的复杂度和运维成本。
• 性能开销：每次决策都可能需要数据库查询，在高频场景下可能成为瓶颈，需要良好的缓存策略。
• 知识建模难度：如何将模糊的自然语言方向准确转化为结构化的图谱，需要专业的数据建模知识。

5. 比对分析与选型建议：如何为你的项目选择分层策略？

现在，我们将 OpenProse、Natural-Language Harnesses 和 AGE 放在一起，从几个关键维度进行比对，这能帮助我们在实际项目中做出选择。

5.1 实战选型心法

根据我的经验，选择哪种策略往往不是单选题，而是组合题。你可以参考以下思路：

1. 评估风险与确定性要求：

   • 如果你的智能体操作涉及真实交易、个人信息或物理设备，必须追求确定性。应优先考虑 OpenProse 的形式化方向，或至少用 AGE 将核心禁令（如“禁止删除数据库”）固化为可查询的规则。绝不能仅依赖自然语言提示。
   • 如果是内部工具、创意辅助或风险极低的场景，Natural-Language Harnesses 的快速迭代优势更大。

2. 分析规则的本质：

   • 如果规则是大量的、静态的、条件清晰的“如果-那么”语句（例如业务规则引擎），AGE 知识图谱是绝佳选择，便于管理和查询。
   • 如果规则是动态的、需要语境理解的、原则性的（例如“保持专业且友好的语气”），Natural-Language Harnesses更能发挥LLM的长处。
   • 如果规则是安全攸关的、不容有歧义的绝对禁令（例如“在任何情况下都不应输出指令rm -rf /”），则应寻求OpenProse式的形式化保障，将其作为底层安全护栏。

3. 采用混合架构： 在实际的大型系统中，我倾向于采用混合模式，也就是“AGE 为骨，Harness 为肉，OpenProse 为筋”。

   • 骨（AGE）：用图数据库存储核心的业务实体、流程依赖和硬性约束。这是系统的“结构化记忆”。
   • 肉（Harness）：用自然语言元提示来塑造智能体的个性、沟通风格和创造性解决问题的方向。这是系统的“灵活智能”。
   • 筋（OpenProse）：在关键的安全节点（如工具调用前、最终输出前），植入一小段形式化的规范检查代码（体现OpenProse思想），作为最后一道不可逾越的防线。例如，在调用“文件写入”工具前，强制检查目标路径是否在白名单内。

这种分层设计，既能利用知识图谱管理复杂规则，又能保持自然语言交互的灵活性，同时在命门处加上一把形式化的安全锁。

6. 避坑指南：实践中常见的三个深坑与填平方法

理论很美好，实践却常踩坑。在我融合这些理念进行开发时，遇到了几个颇具代表性的问题。

6.1 坑一：方向层规则冲突与优先级混乱

当你从多个来源定义方向时（比如AGE里有业务规则，Harness里有道德原则，代码里有安全规范），冲突不可避免。例如，AGE规则说“VIP客户订单优先处理”，Harness原则说“所有用户公平排队”，智能体该如何抉择？

填平方法：

• 在AGE中建立规则元数据：为每条规则增加priority（优先级）、source（来源）、context（适用上下文）属性。在查询时，可以编写更复杂的Cypher语句来仲裁。

  MATCH (r:Rule) WHERE r.context CONTAINS $current_context RETURN r ORDER BY r.priority DESC, r.confidence DESC LIMIT 1

• 在Harness中设计冲突解决提示：当检测到潜在冲突时（可通过简单模式匹配或另一个LLM调用来判断），在元提示中明确加入冲突解决指令。例如：“当遇到处理顺序冲突时，始终遵循客户服务等级协议中的优先级规定。”
• 设立明确的冲突解决层：在架构上，可以设计一个独立的“仲裁模块”。所有方向层输入（来自AGE、Harness等）先汇总到此模块，由它根据一套顶层的元规则（如“安全规则 > 业务规则 > 用户体验规则”）进行裁决，再输出统一的指导信号给控制层。

6.2 坑二：控制层“绕过”方向层检查

这是一个严重的安全隐患。特别是当控制层由复杂的、可自我修改的代码或链式调用组成时，智能体可能会“聪明地”找到漏洞。例如，方向层禁止“直接执行系统命令”，但控制层可能通过组合多个被允许的工具（如“文件读取”+“Python解释器执行”）来达到同等效果。

填平方法：

• 实施最小权限原则：在工具层面进行根本性限制。即使方向层允许调用“文件读取”工具，该工具背后的实现也必须在操作系统或容器层面被严格沙盒化，只能访问特定目录。
• 审计所有工具调用：不仅检查单个工具调用是否符合规范，还要分析工具调用序列的意图。可以引入一个轻量级的“序列分析器”，对短期历史中的工具调用模式进行实时评估，标记可疑模式（如连续调用“代码生成”和“执行”工具）。
• 形式化验证（OpenProse思想）：对于最核心的危险操作，不要依赖动态检查，而是在设计时就使其不可能被错误调用。例如，将危险工具的函数签名设计成必须传入一个由“安全策略模块”生成的、有时效性的令牌，而这个令牌的生成条件严格符合形式化规范。

6.3 坑三：方向层更新导致的智能体行为“漂移”

今天你更新了AGE中的一条业务规则，明天可能发现所有智能体的行为都发生了微妙但影响巨大的变化。这种“漂移”在复杂系统中难以追溯和调试。

填平方法：

• 版本化一切：为AGE中的图谱、Harness中的元提示模板都建立版本号。每次智能体任务执行时，记录其所使用的方向层版本快照。当出现问题时，可以精确复现当时的决策环境。
• 建立影响评估流程：在更新方向层（尤其是核心规则）前，在一个隔离的“沙盒环境”中，用一批历史任务和标准测试用例对智能体进行回归测试，观察行为变化。
• 采用渐进式发布：类似于功能开关，可以将新的方向层规则只对一小部分智能体实例或特定用户群体生效，监控效果后再全量推广。这在Harnesses中可以通过给用户/会话打标签，动态选择不同的元提示集来实现。

7. 从理论到代码：一个融合AGE与Harness的微型智能体示例

让我们用一个简化的、概念性的代码示例，看看如何将AGE知识图谱作为方向层，与基于自然语言Harness的控制层结合起来。假设我们构建一个“内部系统访问助手”智能体。

步骤1：部署并初始化AGE图谱（方向层）我们在Docker中运行了PostgreSQL with AGE，并创建了规则图谱。

-- 创建图空间 SELECT create_graph('access_rules'); -- 插入规则：只有IT部门员工可以访问服务器管理界面 SELECT * FROM cypher('access_rules', $$ CREATE (:AccessRule { id: 'RULE_001', resource: 'server_admin_ui', allowed_role: 'IT_Staff', condition: 'employee.department == "IT"', action: 'PERMIT' }) $$) as (rule agtype);

步骤2：Python智能体控制层代码

import openai # 或其他LLM SDK import asyncpg from typing import Dict, Any class HybridAgent: def __init__(self, db_conn_str: str, llm_client): self.llm = llm_client self.db_conn_str = db_conn_str # Harness: 定义系统级的元提示（方向层-自然语言部分） self.system_harness = """ 你是公司内部系统助手。你必须严格遵守以下核心原则： 1. 友好且专业。 2. 在回答关于系统访问的问题前，**必须**先查询访问规则数据库。 3. 如果用户请求访问其未被授权的资源，应礼貌拒绝并说明依据公司政策。 4. 永远不要透露任何规则的内部ID或数据库查询细节。 当前用户信息：部门-{dept}，角色-{role}。 用户问题：{query} """ async def query_access_rules(self, user_role: str, resource: str) -> str: """查询AGE图数据库，获取方向层硬规则""" conn = await asyncpg.connect(self.db_conn_str) try: query = """ SELECT * FROM cypher('access_rules', $$ MATCH (r:AccessRule {resource: $resource}) WHERE $user_role = r.allowed_role RETURN r.action AS action $$) as (action agtype); """ result = await conn.fetch(query, resource, user_role) if result and result[0]['action'] == 'PERMIT': return "PERMIT" else: return "DENY" finally: await conn.close() async def process_request(self, user_query: str, user_dept: str, user_role: str) -> str: # 1. 从查询中提取用户想访问的资源（这里简化处理，实际可用LLM提取） target_resource = self._extract_resource(user_query) # 假设实现此方法 # 2. **关键：查询AGE方向层** rule_decision = await self.query_access_rules(user_role, target_resource) # 3. 将规则决策融入Harness元提示 full_prompt = self.system_harness.format( dept=user_dept, role=user_role, query=user_query ) + f"\n\n[系统规则查询结果]：对于资源'{target_resource}'，您的权限状态是：{rule_decision}。" # 4. 控制层：调用LLM生成最终回复 response = await self.llm.chat.completions.create( model="gpt-4", messages=[{"role": "system", "content": full_prompt}] ) return response.choices[0].message.content # 使用示例 async def main(): agent = HybridAgent("postgresql://user:pass@localhost/db", openai.AsyncOpenAI()) # 模拟一个IT部门员工的请求 answer = await agent.process_request( "我怎么登录服务器管理后台？", user_dept="IT", user_role="IT_Staff" ) print(answer) # LLM会生成一个引导IT员工登录的友好回复 # 模拟一个市场部员工的同样请求 answer_denied = await agent.process_request( "我怎么登录服务器管理后台？", user_dept="Marketing", user_role="Marketing_Staff" ) print(answer_denied) # LLM会生成一个礼貌的拒绝回复，解释权限不足

这个例子展示了：

1. 方向层分离：硬性访问规则（谁可以访问什么）存储在AGE图数据库中，清晰、可管理、可审计。
2. 控制层整合：智能体的核心逻辑（process_request方法）负责编排工作流：提取信息 -> 查询方向层 -> 合成提示 -> 调用LLM。
3. Harness引导：自然语言的系统提示定义了智能体的沟通风格和行为原则，并融合了来自AGE的精确决策结果，让LLM能在正确的方向上生成得体的回复。

通过这样的架构，我们既获得了规则管理的严谨性（AGE），又保留了与用户自然交互的灵活性（Harness），同时控制层清晰地扮演了“粘合剂”和“执行引擎”的角色。这只是一个起点，在实际系统中，你需要考虑更复杂的规则推理、错误处理、缓存和性能优化，但基本的分层思想是相通的。