人机协作MCP服务器

一个生产就绪的MCP服务器实现,通过14种工具为AI代理添加信任评分、策略约束和人工交接功能,适用于需要人机协作的业务场景。

  • by CoWork-Human-Agent-Protocol
  • TypeScript
  • 本地部署
  • 4 星标
  • 更新于
在 GitHub 查看 kamesh231/cowork-mcp-server

使用说明

@cowork/mcp服务器

人类代理协作原语作为MCP服务器

为任何AI代理添加信任、交接和问责制。生产就绪实施 协同工作协议.


状态

v0.1.1--完成第1、2和3周✅ | 准备好发布npm

组件 状态 已验证
14个MCP工具✅ 已全部注册 添加了cowork_check_handoff(第14个工具)
身份验证 ✅ 开放+封闭模式 销售代理令牌已验证,封闭模式已强制执行
信任评分 ✅ 每(代理、域) 0.3初始值,升级/建议/行动工作,0.8自动升级
模式确定 ✅ 双因素逻辑 高风险领域+信任级别,策略感知
策略引擎 ✅ 约束+归因 5种约束类型,响应中的policy_id,通配符匹配
代理到策略映射 ✅ 三向连接 显式映射:(代理、域、policy_id)
批量操作 ✅ 批准/拒绝N 共享工作_批量批准,共享工作_容量拒绝功能齐全
审计跟踪 ✅ SHA-256哈希链 哨兵代理,提案→ 执行跟踪链接
数量上限执行 ✅ 每(代理、域) 50个提案/小时,在提案时检查,响应中保留的数量
信任衰退 ✅ 延迟评估 每天1%的衰减应用于读取,可配置decay_par_day
切换回调 ✅ 全程往返 代理升级→ 人类决心→ 代理轮询同事_检查_安多夫→ 继续
自动化测试套件 ✅ 49个测试通过 恶作剧:10个信任、17个策略、10个身份验证、12个集成测试
政策归属 ✅ 每个提案 响应包括policy_id、policy_description、rules_checked、mapping_found
npm发布 ✅ 就绪 所有95%的协议都已实现(36/38个原语)

从源代码安装: npm install && npm run build && npm run start npm注册表: 质量测试后1周内到达


这有什么作用

14 MCP工具 为任何AI代理添加协作原语:

工具 原始 它的作用
cowork_propose 意向声明 代理人在行动前提出。信任评分+字段类型决定:行动/建议/升级
cowork_approve 批准信号 人类批准提案。信任+0.02,闭合正反馈回路
cowork_override 覆盖信号 人工纠正代理。信任会降低。5个类别×4个严重级别
cowork_check_trust 信任评分 信任级别+准确性+任何(代理、域)的操作模式
cowork_handoff 上下文包 使用结构化上下文升级到人类:原因、信心、尝试的行动
cowork_check_handoff 切换回拨 代理使用指令轮询已解决的切换。允许在人工升级后继续代理
cowork_log 动作归因 记录与参与者(代理人/人类/协作)的动作
cowork_validate_policy 行动范围 飞行前政策检查。字段约束+策略归因。硬停车与警告
cowork_bulk_approve 批量审批 在一次人工决策中批准50多个提案
cowork_bulk_reject 批量覆盖 以单一原因拒绝多个提案
cowork_resolve_handoff 切换解决方案 人工解决升级问题。手部可根据指示进行操作
cowork_audit_trail 动作归因 全链:建议→ 批准→ 执行→ 验证
cowork_governance_report 干预图 检测孤立的执行、缓慢的决策、缺失的批准
cowork_status 仪表板 信任评分、覆盖率、待决提案、时间表

安装

方案1:地方发展(立即实施)✅

git clone https://github.com/kamesh231/human-agent-cowork-mcp-server.git
cd human-agent-cowork-mcp-server
npm install
npm run build
npm run start

预期产量:

🤝 COWORK MCP Server v0.1.0 started
   Auth: open mode (demo) | Mode: suggest | Trust default: 0.3

克劳德桌面版

编辑 ~/.config/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "cowork": {
      "command": "node",
      "args": ["/full/path/to/human-agent-cowork-mcp-server/build/index.js"]
    }
  }
}

重新启动克劳德桌面→ 协作工具出现了。

克劳德代码

claude mcp add cowork node "$(pwd)/build/index.js"

选项2:全局npm(第3周后推出)⏳

# Not yet available. Will work after npm publish:
npm install -g @cowork/mcp-server

如何实现

步骤1--演示模式(无身份验证)

默认情况下,服务器在 开放模式 --任何 agent_id 已接受,不需要令牌。

npm run start
# Auth: open mode (demo) | Mode: suggest | Trust default: 0.3

所有13个工具立即可用。适合原型制作。

步骤2--注册您的代理(封闭式身份验证)

生成令牌并将其添加到 cowork.config.yaml:

# Generate token + hash for each agent
node -e "
const {generateToken, hashToken} = require('./build/auth.js');
const t = generateToken();
console.log('token:', t);
console.log('hash:', hashToken(t));
"
# cowork.config.yaml
agents:
  - id: "sales-agent"
    token: "sk-cowork-abc123..."     # Dev: plaintext in config
  - id: "support-agent"
    token: "sk-cowork-xyz789..."

服务器输出更改为: Auth: closed mode (2 agents)

生产方式: 使用 token_hash 而不是 token 并通过以下方式加载明文令牌 .env

步骤3——将每个代理映射到其策略

⏳ 第3周功能——即将推出。 目前,所有代理商都共享全球政策。

它解决的问题是: 有了一个全球政策和多个代理,你无法回答“哪个 为哪个代理人解雇了保单?“你无法证实这一点 sales-agent 受CRM规则约束 当 support-agent 获取支持规则,或测试两者在同一域中共享策略。

三段式设计 (策略定义一次,由映射中的ID引用):

# Section 1 — Named rule sets. Define once, share across many agents.
policies:
  - id: "crm-write-policy"
    description: "Standard write access for CRM fields"
    rules:
      - field: "deal_stage"
        constraint: "high_risk"        # always requires human review
      - field: "amount"
        constraint: "value_range"
        min: 0
        max: 500000
      - field: "commission"
        constraint: "readonly"
        reason: "Finance team only"

  - id: "support-write-policy"
    description: "Write access for support ticket fields"
    rules:
      - field: "priority"
        constraint: "enum"
        values: ["low", "medium", "high", "critical"]
      - field: "billing_*"
        constraint: "readonly"
        reason: "Billing fields require finance approval"

# Section 2 — Agent identity only. No rules embedded here.
agents:
  - id: "sales-agent"
    token: "sk-cowork-..."
  - id: "support-agent"
    token: "sk-cowork-..."

# Section 3 — Explicit three-way join: who × where × which rules
mappings:
  - agent_id: "sales-agent"
    domain: "crm.deals"
    policy_id: "crm-write-policy"

  - agent_id: "support-agent"
    domain: "support.tickets"
    policy_id: "support-write-policy"

  # 2 agents → 1 policy: support-agent uses same CRM rules as sales-agent
  - agent_id: "support-agent"
    domain: "crm.deals"
    policy_id: "crm-write-policy"

  # 1 agent → 2 policies: sales-agent has support rules when working tickets
  - agent_id: "sales-agent"
    domain: "support.tickets"
    policy_id: "support-write-policy"

阻塞行为: 如果代理在没有的域中提出建议 mappings 入口,提案 被阻止并升级到请求许可的人。没有沉默的退路。

提案回复将包括启动哪项政策:

{
  "proposal_id": "uuid",
  "mode": "suggest",
  "trust_level": 0.3,
  "high_risk_field": true,
  "policy_id": "crm-write-policy",
  "policy_description": "Standard write access for CRM fields",
  "policy_rules_checked": 3,
  "mapping_found": true
}

这使得政策归因 可测试的: assert(response.policy_id === "crm-write-policy") 无论哪个代理人提出建议,都是明确的。

为什么不使用RBAC? 结构看起来很相似(用户→ role → 许可)但语义 差异:这里的策略是动态的,相同的策略会产生 escalate, suggest,或 act 基于代理人获得的信任分数。RBAC是二进制的(允许/拒绝)。COWORK是梯度 (考虑到这位经纪人的往绩,现在有多大的自主权)。看 WEEK3_PLAN.md 以了解完整的设计原理。

步骤4--配置信任和权限(全局默认值)

# cowork.config.yaml

trust:
  default_level: 0.3              # All agents start supervised
  auto_promote_after: 20          # Promote after 20 approvals
  auto_promote_threshold: 0.8     # At 80%+ approval rate
  auto_demote_after: 3            # 3 consecutive overrides → demotion
  decay_per_day: 0.01             # Trust decays 1%/day without activity (⏳ Week 3)

authority:
  default_mode: "suggest"
  volume_cap: 50                  # Max proposals/hour per agent (⏳ enforced in Week 3)
  high_risk_fields:               # Global: always require human review
    - "deal_stage"
    - "owner"
    - "commission"
    - "utm_*"
    - "billing_*"
    - "password"
    - "permissions"

第五步——联系你的代理人

// Agent proposes before acting
const proposal = await cowork_propose({
  agent_id: "sales-agent",
  agent_token: "sk-cowork-...",
  domain: "crm.deals",
  action: "update_deal",
  target: "deal_12345",
  proposed_change: JSON.stringify({ deal_stage: "closed_won" }),
  confidence: 0.92,
  reasoning: "All criteria met: budget approved, stakeholder consensus",
  field: "deal_stage"
});

// Handle the three operating modes
if (proposal.mode === "act") {
  // Trust ≥ 0.8, proceed autonomously
  await db.update("deals", "deal_12345", { deal_stage: "closed_won" });

} else if (proposal.mode === "suggest") {
  // Trust 0.5–0.8, or field is high-risk — wait for human review
  // deal_stage is in high_risk_fields, so always lands here
  notify.send(`📋 Awaiting review: ${proposal.proposal_id}`);

} else {
  // Trust < 0.5, escalate to human
  await cowork_handoff({
    agent_id: "sales-agent",
    agent_token: "sk-cowork-...",
    domain: "crm.deals",
    reason: "Trust too low to proceed",
    confidence: proposal.confidence,
    attempted_actions: JSON.stringify(["cowork_propose returned escalate"]),
    context: JSON.stringify({ proposal_id: proposal.proposal_id }),
    handoff_mode: "escalate"
  });
}

第6步——整合人类反馈

// Approve — closes the positive feedback loop
await cowork_approve({
  proposal_id: "uuid",
  agent_id: "sales-agent",
  domain: "crm.deals",
  feedback: "Looks good — legal confirmed"
});
// Effect: trust +0.02, proposal marked approved

// Correct — closes the negative feedback loop
await cowork_override({
  agent_id: "sales-agent",
  domain: "crm.deals",
  action_description: "Deal closure was premature",
  override_type: "agent_wrong",
  severity: "high",
  description: "Contract still being negotiated"
});
// Effect: trust -0.12 (0.08 × 1.5 severity), consecutive_overrides +1

如何确定模式

cowork_propose 用途 双因素逻辑 设置操作模式:

因素1:高风险现场检查

如果正在修改的字段位于 high_risk_fields (或第3周后的每个代理策略规则):

deal_stage, owner, commission, utm_*, billing_*, password, permissions
→ Mode = "suggest" regardless of trust level

因素2:基于信任的检查(适用于非高风险领域)

trust < 0.5   → mode = "escalate"   (human must handle it)
0.5 ≤ trust < 0.8 → mode = "suggest"    (propose and wait for approval)
trust ≥ 0.8   → mode = "act"        (proceed autonomously)

已验证的响应结构

现场试运行测试和确认:

{
  "proposal_id": "9f8710ef-c245-4c19-9ff1-810ac300c185",
  "action_id": "e5c3a1d2-4f6b-11ec-81d3-0242ac130003",
  "mode": "escalate",
  "trust_level": 0.3,
  "confidence": 0.85,
  "high_risk_field": false,
  "policy_warnings": 0,
  "message": "🚨 ESCALATED: Trust (0.30) too low. Proposal 9f8710ef..."
}

关键字段名称: trust_level (不是 trust.score), high_risk_field (布尔值)。


域和代理映射

代理人已明确注册

agents:
  - id: "sales-agent"
    token: "sk-cowork-abc..."
  - id: "support-agent"
    token: "sk-cowork-xyz..."

每次工具调用都必须包括匹配 agent_id + agent_token。服务器在关闭模式下拒绝未知代理。

域名由代理人选择(有机)

域名是 未预先注册 --代理人在提案时为他们命名。任何字符串都可以:

// Domains are just strings agents choose
domain: "crm.deals"          // sales agent's scope
domain: "support.tickets"    // support agent's scope
domain: "docs.api-ref"       // documentation agent's scope

信任按(agent_id,domain)对进行跟踪:

sales-agent : crm.deals         → trust 0.85 → mode: act
sales-agent : crm.contacts      → trust 0.40 → mode: suggest
sales-agent : support.tickets   → trust 0.30 → mode: escalate
support-agent : support.tickets → trust 0.72 → mode: suggest

同一代理在一个域中可以被信任,但在另一个域则不能。


覆盖类别和严重性

当人类纠正代理时,他们会进行分类 为什么:

类别 基础影响 何时使用
agent_wrong −0.08 事实或逻辑错误
missing_context −0.03 应该升级,没有信息
edge_case −0.02 异常情况,难以预料
human_preference −0.01 代理是正确的,人类更喜欢不同的方法
policy_change 0.00 规则改变了——不是代理人的错

严重性乘数 缩放基础影响:

严重性 乘数 示例
low 0.5× 次要措辞偏好
medium 1.0× 标准校正
high 1.5× 严重错误,后果严重
critical 2.5× 违反政策或重大失误

例子: agent_wrong + high 严重程度=-0.08×1.5= -0.12信任


音量上限执行

代理人受到速率限制,以防止失控行为。限制是 每(代理、域)对:

# cowork.config.yaml
authority:
  volume_cap: 50  # Max proposals per hour

执行: 每 cowork_propose call会检查过去60分钟内的提案计数(agent_id,domain)。如果代理人超过此提案的上限,则该提案将被拒绝 VolumeCapError.

响应包括反馈:

{
  "volume_cap": 50,
  "volume_remaining": 12,
  "proposal_id": "uuid",
  "mode": "suggest"
}

这允许代理人监控自己的费率并自愿退出。


信任衰退

代理在不活跃时会逐渐失去信任。这防止了“一次赢得信任,永远滑行”

# cowork.config.yaml
trust:
  decay_per_day: 0.01  # 1% per day

它是如何工作的:

  • 在阅读时懒散地应用Decay(不需要背景工作)
  • 每次 cowork_check_trust 或 cowork_propose 运行时,信任分数将重新计算
  • 公式: new_score = current_score - (days_since_last_activity × decay_per_day)
  • 最小信任度:0.1(永远不会低于此值)

例子: 如果0.8信托的代理人在10天内停止求婚:

0.8 - (10 × 0.01) = 0.8 - 0.1 = 0.7  (now in "suggest" mode instead of "act")

通过再次提议或获得批准来重置衰变。每次审批和提案活动时间戳都会重置衰减时钟。


切换回叫循环

当代理通过以下方式升级时 cowork_handoff他们不会就这样消失。人类可以将工作交还给指令,代理会轮询这些指令。

代理流

// Step 1: Agent escalates
const handoff = await cowork_handoff({
  agent_id: "sales-agent",
  domain: "crm.deals",
  reason: "Trust too low to modify deal_stage",
  confidence: 0.85,
  attempted_actions: JSON.stringify(["check budget", "verify stakeholders"]),
  context: JSON.stringify({ deal_id: "12345", issue: "..." })
});

// Agent receives handoff_id and waits
const handoff_id = handoff.handoff_id;

// Step 2: Human resolves with instructions (happens in UI or via cowork_resolve_handoff)
// Human chooses: approve and/or hand back with instructions
// Example: "You can proceed, but only if both stakeholders have confirmed in writing"

// Step 3: Agent polls for the resolution and instructions
const callback = await cowork_check_handoff({
  agent_id: "sales-agent",
  domain: "crm.deals"  // optional — omit to check all domains
});

if (callback.pending_handoffs.length > 0) {
  const handoff = callback.pending_handoffs[0];
  if (handoff.hand_back === true) {
    // Human handed work back with instructions
    console.log("Instructions:", handoff.instructions);
    // "Check for written stakeholder confirmation before proceeding"

    // Verify constraint and try again
    if (stakeholders_confirmed) {
      await cowork_propose({ /* same proposal */ });
    }
  }
}

人流

// Human sees escalated work in dashboard
const status = await cowork_status({ agent_id: "sales-agent" });
// Shows pending handoffs with agent's reasoning and context

// Human resolves with instructions
await cowork_resolve_handoff({
  handoff_id: "uuid",
  resolution: "approved",
  hand_back: true,  // Agent can continue
  instructions: "Proceed only if both stakeholders have written confirmation in the deal notes"
});

// Agent's next cowork_check_handoff call returns this instruction
// Agent can now take informed action or ask clarifying questions

本协议解决的真实案例

CRM数据完整性(HubSpot案例)

CRM案例研究描述了一个具有完全写访问权限的代理,该代理会悄无声息地损坏以下对象的数据 3周。根本原因:没有字段限制,没有卷上限,没有审批流。

COWORK提供什么:

  • high_risk_fields 阻止直接写入deal_stage、commission、utm_*
  • volume_cap 以每小时50个提案的速度暂停代理(在第3周执行)
  • cowork_propose 在任何写入操作之前创建一个暂存层
  • cowork_override 分类原因创建了一个反馈循环

支持切换故障(对讲机案例)

50%的对话需要人工切换。每次交接都会失去背景——人类 重新阅读完整的成绩单,客户重复了一遍。

COWORK提供什么:

  • cowork_handoff 承载结构化语境:理性、自信、尝试
  • 按域信任(support.tickets 与...分开 billing.issues)
  • cowork_resolve_handoff 让人手根据指令进行回拨(第3周回拨)

跨环境上下文丢失

两个代理(Claude Desktop+Claude Code)共享一个文件系统,但不共享决策状态。 em dash事件:Claude Desktop在不知情的情况下批准了80个替代品 为什么 它们被制造出来了。

COWORK提供什么:

  • cowork_handoff 上下文数据包携带 决策状态,而不仅仅是输出状态
  • cowork_log 和 actor: "agent" 环境做出改变的属性
  • 时间线事件允许重建跨环境序列

测试

自动化测试套件(Jest)✅

npm test

49项测试,4个类别,全部通过:

信任和模式确定(10次测试)

  • 初始信任默认为0.3→ 模式=升级
  • 高风险字段(交易阶段)→ 模式=不顾信任而建议
  • 信任0.85→ 模式=动作(自主)
  • 批准增加信任+0.02
  • 使用严重性倍数(高:1.5倍)覆盖会正确降低信任度
  • 连续3次覆盖会触发降级
  • 正确应用信任衰减(每天1%)
  • 20次批准后,汽车推广的批准率达到80%

策略映射和归因(17项测试)

  • 2个代理+1个政策:销售代理和支持代理都使用crm编写政策
  • 1个代理+2个策略:销售代理在crm.deals中使用crm写入策略,在support.tickets中使用支持写入策略
  • 未映射的域返回mapping_found=false(正常升级)
  • 评估的策略约束:高风险、只读、值范围、枚举、正则表达式
  • 通配符匹配有效(billing_*匹配billing_amount、billing_status)
  • 响应中的策略归因:Policy_id、Policy_description、rules_checked

身份验证(10次测试)

  • 销售代理令牌根据配置进行验证
  • 无效令牌引发AuthError
  • 打开模式接受任何agent_id
  • 关闭模式拒绝未知代理
  • 令牌生成和哈希工作正常

集成(12次测试)

  • 具有身份验证+策略解析的完整共享工作_角色流
  • 执行音量上限(50/小时),并提供音量维持反馈
  • 高风险现场检测+政策规则检查计数
  • 切换回叫循环:升级→ 解决→ 代理民意调查→ 继续
  • 模式确定既尊重高风险检查,也尊重基于信任的检查

覆盖

npm test -- --coverage

为所有14个工具生成覆盖率报告。当前覆盖率:核心路径的92%。

MCP检查员(交互式)

npm run inspect

打开基于浏览器的工具,手动调用14个工具中的任何一个,查看实时响应,检查数据库状态。


建筑

文件 目的
src/index.ts 14 MCP工具处理程序、身份验证中间件、提案→ 响应管道
src/trust.ts 通过SQLite事务、衰变计算进行原子信任突变
src/storage.ts SQLite模式:7个表(建议、信任_核心、操作、覆盖、切换、时间线、audit_log)、所有查询、迁移支持
src/auth.ts 令牌生成、验证、打开/关闭模式切换
src/policy.ts 策略引擎:三向映射解析、5种约束类型、通配符匹配、高风险字段检测
src/config.ts 配置模式:策略(命名规则集)、代理(身份)、映射(显式连接)、信任默认值、权限规则
src/audit.ts 审计链、治理问题检测、提案→执行链接
src/bulk-decision.ts 使用原子更新批量批准/拒绝操作
src/notify.ts 多渠道通知框架(电子邮件/Slack/webhook的占位符)
src/sentry/ 审计代理——拦截工具调用、意图验证、哈希链日志记录
tests/unit/ 37个单元测试:信任(10)、策略(17)、身份验证(10)
tests/integration/ 12个集成测试:具有auth+策略解析的完整MCP流

生产特点:

  • ✅ 所有信任突变 BEGIN EXCLUSIVE SQLite事务(无TOCTU竞赛)
  • ✅ 在所有14个工具上使用带有Zod输入验证的完整TypeScript
  • ✅ 显式策略映射(三方连接),并响应归因
  • ✅ 开放模式用于原型制作,封闭模式用于生产
  • ✅ 哨兵追踪中的SHA-256哈希链(防篡改)
  • ✅ 在建议时间执行交易量上限并提供反馈
  • ✅ 信任衰退懒洋洋地应用于阅读(没有背景工作)

协议对齐

类别 图元 已实现 状态
信任 分数、阈值、证据、衰减、自动提升 5/5 ✅ 完成
权限 行动范围、交易量上限、高风险领域 3/3 ✅ 完成
切换 上下文包、升级触发器、回调 3/3 ✅ 完成(第3周)
反馈 超控信号、批准信号、批量 3/3 ✅ 完成
沟通 信心、推理、意图声明 3/3 ✅ 完成
可观察性 归因、时间线、治理 3/3 ✅ 完成
策略 验证、归因、约束评估 3/3 ✅ 完成(第3周)
推迟到v0.2.0 质量指标,结构化推理模式 2/2 ⏳ 未来
总计 36核+2高级 36/38 (95%) ✅ 第3周完成

详细信息: 协议_忽略.md


第3周实施✅

日 特征 状态 影响
1 代理到策略映射(三方连接) ✅ 完成 政策现在明确命名、可重用、可归因于响应
2-3 自动化测试套件(Jest,49个测试) ✅ 完整 全面覆盖:信任、策略、身份验证、集成流程
4 执行交易量上限(50/小时)+信任衰减(1%/天) ✅ 完成 两者都在运行时检查,延迟评估衰减
5 交接回叫(同事_检查_交接) ✅ 完成 代理可以轮询人工指令,升级后可以继续

详细计划和实施说明: WEEK3_PLAN.md

准备好了什么:

  • ✅ 14个工具功能齐全
  • ✅ 实现了36/38个COWORK协议原语(95%)
  • ✅ 生产就绪:SQLite事务、原子信任突变、Zod验证
  • ✅ 49项自动化测试全部通过
  • ✅ 策略属性可测试(响应中的Policy_id)
  • ✅ 响应中的容量上限反馈(Volume_remaining字段)
  • ✅ 切换回叫环路完全运行

什么被推迟到v0.2.0:

  • 质量指标收集(图元#37)
  • 结构化推理模式(原语#38)

存储

  • 默认:SQLite位于 ./cowork.db
  • 表格:建议、信任核心、行动、覆盖、移交、时间表、审核日志
  • 访问: sqlite3 cowork.db 或使用 cowork_status 和 cowork_audit_trail 工具
  • 哨兵痕迹:单独数据库位于 ./cowork-traces.db 使用哈希链

链接

  • COWORK协议规范: https://github.com/kamesh231/cowork-protocol
  • 此Repo: https://github.com/kamesh231/human-agent-cowork-mcp-server
  • 第3周计划: WEEK3_PLAN.md
  • 协议对齐: 协议_忽略.md

许可证

麻省理工学院——在商业或开源项目中自由使用。