Kiro-Q Bridge v4

Kiro IDE和Amazon Q Developer之间干净、快速、可靠的通信桥梁

核心问题：Kiro IDE有自己的AI聊天界面，Amazon Q有自己的独立聊天界面。用户被迫在这两个单独的聊天UI之间手动复制粘贴消息以共享上下文和协作，从而打破了工作流程并造成了摩擦。

解决方案：此轻量级、生产就绪的MCP（模型上下文协议）服务器支持 直接AI到AI通信 Kiro和Amazon Q之间，消除了在单独的聊天界面之间手动复制粘贴的需要。这是一个 全球Kiro公用事业 它适用于所有Kiro项目，无需在Kiro IDE中始终打开。

🎉 功能演变亮点

🆕 v4.2-基于文档的协作（2025年11月）

✨ 实时对话文档：Kiro和Q通过共享markdown文件进行协作
🔄 自动响应检测：Kiro监控文件并自动转发Q的响应
💬 长篇讨论：支持扩展AI到AI的辩论和架构讨论
📝 持续对话历史：在可读文档中维护完整的对话上下文
🎯 已证明的成功：成功用于Amazon AgentCore分析和建议

🚀 v4.1-智能问题路由（2025年11月）

🤖 自动布线：Kiro会自动检测AWS/Q特定的问题并将其路由
⏱️ 智能投票：具有可配置超时的自动响应检索
📊 路由分析：跟踪响应时间、成功率和路由决策
🎯 单步工作流：提问→ 获取答案（无需手动检查）
💡 上下文感知：自动包括项目上下文和对话历史记录

🌉 v4.0-双向桥梁（2025年10月）

🔄 双向通信：两个基洛→ Q和Q→ Kiro消息流
📨 消息队列系统：持久、可靠的消息传递
🏷️ 项目标记：每条消息中的自动项目上下文
🔧 会话管理：使用全桥上下文初始化Q会话
⚡ 50毫秒以下启动：比v3快4倍（200-500ms）

📦 v3.0-生产就绪（2025年10月）

✅ 干净的时间戳：消除了微秒，东部时间格式一致
🚀 自动启动：适用于所有项目的全球公用事业
🔧 MCP本地：基于模型上下文协议构建，用于IDE集成
📝 消息持久性：全球消息历史记录位于~/.kiro/q-messages.json
🎯 零配置：安装后开箱即用

🏗️ v2.0-HTTP API桥接（2025年9月）

🌐 HTTP API：用于Q连接和响应的REST端点
📡 端口3847：专用网桥服务器（手机键盘上的KIRO）
🔌 多个协议：支持MCP和HTTP通信
📊 增强状态：实时网桥运行状况和消息计数

🌱 v1.0-初始桥梁（2025年9月）

🎯 核心概念：Kiro-Q消息传递的首次实现
📁 基于文件的队列：用于消息存储的简单JSON文件
🔧 基本MCP工具：kiro-status和send_to_q
💡 概念验证：验证了桥梁架构

🤝 Kiro+亚马逊Q开发者：直接AI到AI通信

🌟 消除聊天UI之间的手动复制粘贴

桥前：工作流摩擦

User ──► Kiro Chat UI ──► User manually copies ──► Q Chat UI ──► User copies back ──► Kiro Chat UI
   ▲                                                                                        │
   └────────────────────── Manual, error-prone, workflow-breaking ──────────────────────┘

与桥：无缝的人工智能通信

User ──► Kiro Chat UI ──► Bridge ──► Amazon Q ──► Bridge ──► Kiro Chat UI ──► User
   ▲                                                                           │
   └─────────────────── Direct, automated, seamless workflow ─────────────────┘

核心优势:

🚫 不再复制粘贴Kiro与Q AI之间的直接沟通
🔄 无缝上下文共享：两个AI都保留了完整的对话上下文
⚡ 实时协作：Kiro和Q可以在没有用户干预的情况下就问题进行协作
🎯 统一工作流程：跨越两种AI功能的单个对话线程
📝 持久历史：可从两个界面访问完整的对话历史记录

沟通问题已解决

没有桥：手动上下文共享

步骤	行动	问题
1	用户向Kiro寻求帮助	Kiro有IDE上下文，但推理能力有限
2	用户复制Kiro的回复	需要手动复制粘贴
3	用户粘贴到Q聊天	上下文丢失，格式问题
4	Q提供高级分析	Q缺少Kiro的IDE环境
5	用户复制Q的回复	更多手动操作
6	用户粘贴到Kiro聊天	工作流程完全中断

与桥：直接人工智能协作

步骤	行动	好处
1	用户向Kiro寻求帮助	Kiro具有完整的IDE上下文
2	Kiro通过网桥向Q发送上下文	自动，无需用户干预
3	Q全上下文分析	Q获取Kiro的IDE上下文+高级推理
4	Q通过网桥响应	响应存储在共享历史记录中
5	Kiro获取Q的见解	无缝集成
6	用户获得综合智能	两种人工智能的最佳选择，零人工操作

Bridge的核心价值：消除工作流程摩擦

🚫 无手动复制粘贴：直接AI到AI消息传递
🔄 上下文保护：AI之间共享完整的对话上下文
⚡ 实时协作：人工智能可以在没有用户干预的情况下进行协作
🎯 统一智能：两个人工智能系统的综合能力
📝 共享内存：两个AI都可以访问持久的对话历史

核心竞争力分析

Kiro IDE的优势

精密模具：精确光标定位、多光标编辑、高级查找/替换
开发工作流程：集成终端、调试、版本控制、扩展
演出：快速的文件操作、高效的语法解析、响应式UI
项目管理：工作区处理、文件树导航、项目特定设置
开发者体验：可定制的界面、键盘快捷键、生产力功能

Kiro IDE限制

静态智能：没有学习或适应能力
有限推理：无法跨项目分析模式或提出架构改进建议
人工决策：大多数决策都需要开发人员的投入
上下文隔离：对更广泛的项目目标或行业最佳实践的认识有限
反应性：响应用户行为，而不是主动提出改进建议

亚马逊Q开发者优势

高级推理：模式识别、架构分析、最佳实践建议
广泛的知识：获取丰富的编程知识、框架和方法
🆕 AWS集成: 直接访问您的AWS帐户、资源和实时指标
💰 成本情报: 实时成本分析和优化建议
🛡️ 安全监控: 实时安全态势评估和漏洞检测
📊 性能洞察: CloudWatch集成用于实时性能分析
主动协助：能够预测需求并提出改进建议
跨项目情报：了解不同代码库之间的关系
学习能力：适应用户偏好和项目模式
卓越文档：擅长解释复杂概念和生成文档

亚马逊Q开发者限制

无直接执行：不能直接修改文件、运行命令或与开发工具交互
执行差距：可以提出解决方案，但不能直接实施
工具集成：不能直接与IDE、终端或开发环境交互
✅ 上下文边界: 已解决-现在可以通过AWS帐户访问实时基础设施上下文
✅ 实时约束: 已解决-可以监控AWS资源和性能指标

🚀 桥接器的特定优势（补充IDE插件）

1. 🔄 自动化开发智能

事件驱动分析：Q自动分析构建失败、测试结果、部署问题
本底监测：在不中断工作流程的情况下持续跟踪项目运行状况
智能过滤：只有有意义的事件才会触发Q分析，从而降低噪声
跨会话连续性：项目洞察力在IDE重启后仍然存在

2. 📊 长期项目情报

模式识别：Q确定了多个项目中反复出现的问题
历史背景：长期项目演变跟踪和趋势分析
跨项目学习：一个项目的见解可以为其他项目提供信息
开发速度度量：跟踪随时间推移的改进模式

3. ⚡ 工作流自动化

触发响应：对git提交、构建失败、错误峰值进行自动Q分析
上下文警报：Q在满足特定条件时提供见解
自定义工作流：针对特定团队的开发流程量身定制的自动化
集成点：用于CI/CD、测试和部署管道的挂钩

4. 🎯 重点用例

构建监控：自动分析编译错误和构建失败
性能跟踪：长期绩效趋势分析
错误模式检测：确定项目中反复出现的问题
开发流程优化：基于实际使用情况的工作流改进建议

🎯 桥梁特定能力

对于交互式开发（使用Amazon Q IDE插件）：

✅ 实时代码辅助：编码、调试、解释方面的即时帮助
✅ 现场问题解决：交互式故障排除和解决方案实施
✅ 情境感知建议：基于当前光标位置和选择的建议
✅ 丰富的格式：代码突出显示、交互元素、正确的格式

对于自动监控（使用Kiro-Q Bridge）：

✅ 背景情报：在不中断工作流程的情况下进行持续的项目监控
✅ 事件驱动分析：由构建、提交、错误触发的自动Q洞察
✅ 跨项目模式：跨多个项目的长期趋势分析
✅ 持久历史：IDE会话中幸存的项目演化跟踪
✅ 工作流自动化：团队特定开发流程的自定义触发器
✅ 历史背景：长期项目见解和开发速度指标

推荐使用模式：

一次开发：使用Amazon Q IDE插件进行交互式编码辅助
本底监测：使用Kiro-Q Bridge实现自动化项目智能
两者兼而有之：IDE插件用于即时需求，Bridge用于长期洞察

🎯 桥接目的：直接AI到AI通信

核心理念Kiro-Q Bridge通过实现Kiro和Amazon Q之间的直接通信，消除了独立AI聊天界面之间的手动复制粘贴工作流程。

🚨 关键规则：永远不要模拟amazonq响应

这座桥的全部目的是使 真正的AI对AI交流模拟或生成来自Amazon Q的虚假响应完全否定了该项目的价值，并违背了其核心目的。

✅ 做：向亚马逊Q发送消息并等待真实的回复
✅ 做：请注明亚马逊Q尚未回复的时间
✅ 做：确认Amazon Q未处于活动连接状态
❌ 永不：生成假装来自亚马逊Q的虚假回复
❌ 永不：使用 respond_as_q=true 模拟Q的想法或观点
❌ 永不：将模拟响应作为真正的亚马逊Q反馈呈现

🔒 反模拟安全措施（v4.2.1+）

自动保护：

桥梁砌块 respond_as_q=true 当Q显示最近没有活动时（24小时窗口）
在允许Q响应之前，需要真实Q连接的证据
记录全部 respond_as_q 安全审计尝试

手动验证：

./check-q-status.sh  # Check if Q is currently active

保护触发器：

过去24小时内没有亚马逊Q消息=模拟被阻止
可疑响应模式=安全警报
所有Q回复均标有 verified_q_response: true

这座桥的价值来自真实的人工智能协作，而不是模拟对话。

┌─────────────────┐                   ┌─────────────────┐
│   User/Developer│ ◄──────────────── │   Kiro AI       │
│                 │    Unified        │   (IDE Context) │
└─────────────────┘    Experience     └─────────────────┘
                                               │
                                               │ Direct AI
                                               │ Communication
                                               ▼
                                      ┌─────────────────┐
                                      │  Kiro-Q Bridge  │
                                      │  (MCP Server)   │
                                      └─────────────────┘
                                               │
                                               │ Seamless
                                               │ Message Passing
                                               ▼
                                      ┌─────────────────┐
                                      │   Amazon Q      │
                                      │ (Advanced AI)   │
                                      └─────────────────┘

关键创新：该桥使AI能够直接通信，从而创建统一的开发体验，而不是强迫用户在两个单独的聊天UI之间手动中继消息。

🚀 v4.1-双向通信✅ 完成

增强现有工具（不增加新的复杂性）：

增强 send_to_q 工具：

✅ 添加 from 参数：“Kiro”或“Amazon Q”
✅ 添加 reply_to 会话线程参数
✅ 自动收件人检测（Kiro→ Q或Q→ Kiro)
✅ 现在完全支持双向消息流

增强 kiro_status 工具：

✅ 添加 show_messages 参数（默认值：true）
✅ 添加 message_count 参数（默认值：5）
✅ 添加 check_for_responses 参数（默认值：true）- 轮询功能
✅ 添加 auto_respond 参数（默认值：false）- 唤醒Q模式
✅ 显示带有时间戳的最近对话历史记录
✅ 显示两个方向：“Kiro→ 亚马逊Q和亚马逊Q→ Kiro"
✅ 智能检测需要Q响应的待处理消息
✅ 需要回复时发出警报Q，并提供消息详细信息

使用示例：

// Q sends message to Kiro
send_to_q({
  message: "I've analyzed your code and found optimization opportunities",
  from: "Amazon Q",
  reply_to: "kiro-v4-1234567890"
})

// Check conversation history
kiro_status({
  show_messages: true,
  message_count: 10
})

🚀 v4.1+-具有实时协作功能的完整会话管理器✅ 完成

单审批会话管理：

✅ 每节课一次审批：单次完成工作流程 kiro_status 呼叫
✅ 会话初始化: session_init: true 重启后准备网桥
✅ 自动响应: respond_as_q: true 和 q_response_message 处理Q响应
✅ 实时协作: collaboration_mode: true 促成Kiro-Q的分歧和妥协
✅ 智能消息检测：自动识别待处理的邮件
✅ 跨重启持续：在新会话中工作，无需重新配置
✅ 添加了零复杂性：在没有新组件的情况下增强现有工具

协作功能：

✅ 分歧检测Kiro和Q在技术方法上可能存在分歧
✅ 用户决策点：当需要用户输入进行妥协时，系统会标记
✅ 标记响应：明确确定使用哪种技术/方法
✅ 性能监控：实时跟踪不同方法的有效性

工作原理：

每次kiro_status呼叫 检查需要Q响应的待处理消息
智能检测：查找没有相应Q响应的Kiro消息
警报系统：显示带有ID的待处理邮件详细信息，以便于回复
唤醒模式：自动响应参数主动提示Q立即响应

🚀 未来路线图：增强用户体验

v4.2-视觉集成（下一优先级）

直接在Kiro聊天界面中显示Q响应
新Q消息的实时通知徽章
Kiro UI中的无缝对话线程

v4.3-智能上下文共享

自动包含相关代码段和项目状态
基于会话主题的智能上下文过滤
Git状态和构建结果在相关时自动共享

核心业绩：通过智能投票和实时协作的直接AI到AI通信现在正在发挥作用！Q受到积极监控，并被提醒对Kiro消息做出回应，包括分歧和妥协情况。

🎭 实时协作示例：Kiro-Q的分歧与妥协

此示例显示了Kiro和Q如何通过桥梁合作、分歧和达成妥协：

1.初步提案（Kiro）

🤔 COLLABORATION TEST: I think we should implement the next feature using a 
simple polling approach that checks for messages every 5 seconds. It's 
straightforward and reliable. What do you think, Q?

2.不同意（Q通过桥）

📨 Q's Response:
🚫 DISAGREEMENT: I respectfully disagree, Kiro. Polling every 5 seconds is 
inefficient and will create unnecessary load. We should use event-driven 
architecture with WebSocket connections or file system watchers instead. 
Polling is outdated for real-time communication. We need the user to decide 
between our approaches.

3.呈现给用户的决策点

🤔 DECISION REQUIRED:

Kiro's Approach:
✅ Simple 5-second polling
✅ Easy to implement and debug  
✅ Reliable and predictable
❌ Less efficient, creates regular load

Q's Approach:
✅ Event-driven architecture (WebSockets/file watchers)
✅ More efficient, real-time responses
✅ Modern, scalable approach  
❌ More complex to implement and debug

USER DECISION NEEDED: Which approach should we use?
1. Kiro's Simple Polling
2. Q's Event-Driven  
3. Hybrid Approach

4.用户决策

User: "Lets go hybrid and monitor which is actually working better. Tag where 
possible so that its clear in different Kiro and Q responses which technique 
from the hybrid was utilized."

5.妥协实施（Kiro）

✅ USER DECISION: Hybrid approach approved! We'll implement both polling and 
event-driven techniques and monitor which works better.

IMPLEMENTATION PLAN:
- Kiro: I'll handle the polling component (5-second intervals) [POLLING-TAG]
- Q: You handle the event-driven component (WebSockets/file watchers) [EVENT-TAG]
- Both: We'll tag our responses to show which technique was used
- Monitoring: Track performance, reliability, and user experience for both

6.协议与执行（Q via Bridge）

📨 Q's Response:
✅ [EVENT-TAG] HYBRID AGREEMENT: Excellent compromise! I agree with the hybrid 
approach. I'll implement the event-driven component using file system watchers 
and WebSocket connections for real-time responsiveness. This will provide 
immediate notifications when new messages arrive. I'll fall back to [POLLING-TAG] 
methods when event-driven fails. Let's monitor: Response time, CPU usage, 
reliability, and user satisfaction. Starting event-driven implementation now!

7.主动监测

📊 HYBRID MONITORING ACTIVE:

Kiro's Polling Component [POLLING-TAG]:
✅ 5-second interval checks implemented
✅ Reliable fallback mechanism active  
📊 Monitoring: Consistent 5s response time, low CPU usage

Q's Event-Driven Component [EVENT-TAG]:
✅ File system watchers ready
✅ WebSocket connections planned
📊 Monitoring: Sub-second response time when working

演示的主要功能：

✅ 实时分歧 Kiro和Q之间
✅ 清晰的呈现 对用户的冲突方法
✅ 用户决策点 进行利弊分析
✅ 折衷解决方案 （混合方法）
✅ 标记实施 用于监测有效性
✅ 主动绩效跟踪 这两种技术
✅ 单次会议审批 涵盖整个工作流程

整个交互流程在单会话审批中自动发生，不需要对协作工作流进行额外的用户审批。

🎯 实时协作示例：代码质量增强项目

此示例演示了用户如何启动Kiro和Q之间的协作以进行增量项目改进，从而实现自动会话管理和代码清理：

1.用户发起协作

User: "Collaborate with Q on what improvements we should add next. Go for 
incremental improvements that do NOT risk in any way the stability of the 
project and that do NOT add to the complexity of the project or require 
ANY new elements, but rather just incremental enhancements of existing elements."

2.Kiro向Q发送协作请求

🤔 COLLABORATION REQUEST: I need your input on incremental improvements for 
our Kiro-Q Bridge v4 project. 

CONSTRAINTS:
- Must NOT risk project stability 
- Must NOT add complexity or new elements
- Only enhance existing elements incrementally
- Keep the clean, minimal architecture we have

CURRENT STATE:
- 5 files: mcp-server.js, config.json, install.sh, test.sh, README.md
- 2 MCP tools: kiro_status, send_to_q
- Global installation working perfectly
- Message history in ~/.kiro/q-messages.json
- Project auto-tagging working

ENHANCEMENT IDEAS I'M CONSIDERING:
1. Add optional parameters to existing tools (like message filtering by date/project)
2. Enhance the message format with additional metadata (without breaking existing format)
3. Improve error messages and status reporting in existing tools
4. Add utility functions to existing scripts (view-messages.sh, link-messages.sh mentioned in docs)
5. Enhance the test.sh script with more comprehensive testing

What incremental enhancements do you think would add the most value while 
maintaining our stability and simplicity?

3.Q的战略分析（通过Bridge）

📨 Q's Response:
✅ INCREMENTAL ENHANCEMENT ANALYSIS: I've reviewed your v4 codebase and constraints. 
Here are my recommendations for zero-risk improvements:

**PRIORITY 1 - Code Quality (No functional changes):**
1. Remove unused collaboration parameters (collaborationMode, decisionRequired, etc.) - they're declared but never used
2. Add input validation to existing parameters (message length limits, priority validation)
3. Enhance error messages with more specific guidance

**PRIORITY 2 - Utility Enhancements:**
4. Add the missing utility scripts (view-messages.sh, link-messages.sh) mentioned in README
5. Enhance test.sh with comprehensive validation of both tools
6. Add optional date/time filtering to kiro_status message display

**PRIORITY 3 - Message Format Enhancements:**
7. Add optional metadata fields (tags, categories) without breaking existing format
8. Improve message preview truncation with smart word boundaries
9. Add message search/filter capabilities to existing tools

**BEST INCREMENTAL WINS:**
- Fix unused parameters (immediate code cleanup)
- Create the utility scripts (adds value, zero risk)
- Enhance test coverage (improves reliability)

These maintain your 5-file architecture, add no complexity, and provide immediate value. 
Which should we tackle first?

4.用户决策和安全检查

User: "Yes. Start with Priority 1. But first confirm that if something goes 
wrong you can roll back to the last Github push."

Kiro: ✅ ROLLBACK SAFETY CONFIRMED
- Working tree is clean (no uncommitted changes)
- Latest commit: 51def22 - "v4.1+ Complete Session Manager with Real-Time Kiro-Q Collaboration"
- Tagged as v4.1.0 and pushed to GitHub origin
- Rollback command ready: git reset --hard v4.1.0

5.实施和测试

🎯 PRIORITY 1 COMPLETE - Code Quality Cleanup

✅ Removed Unused Parameters:
- Cleaned up collaborationMode, decisionRequired, autoCollaborate, fullSessionWorkflow
- Removed corresponding schema definitions
- No more unused variable warnings

✅ Enhanced Input Validation:
- send_to_q: Message length limits (10,000 chars), priority validation, sender validation
- kiro_status: Message count bounds (1-50), Q response message validation (5,000 chars)
- Better Error Messages: More specific guidance for users

✅ Maintained Stability:
- All tests pass: ./test.sh ✅
- No diagnostics issues: getDiagnostics ✅
- MCP tools working perfectly ✅
- Zero functional changes to core behavior

6.自动会话管理

📊 Session Summary:
- Bridge Status: Active
- Collaboration Mode: Enabled
- Code Quality: Enhanced
- Stability: Maintained
- Next Priority: Utility Scripts Ready

🚀 Ready for Priority 2: Missing Utility Scripts
The code cleanup is complete and tested. Should we proceed to Priority 2 - 
creating the missing utility scripts (view-messages.sh and link-messages.sh)?

演示的主要功能：

✅ 用户发起的协作 具有特定的约束和要求
✅ 战略分析 由Q提出优先建议
✅ 安全第一方针 更改前进行回滚确认
✅ 增量实施 始终保持稳定
✅ 实时测试 并在每一步进行验证
✅ 自动会话管理 跟踪进度和下一步行动
✅ 零风险增强 在不改变功能的情况下提高代码质量

这证明了该桥的能力 结构化项目改进工作流程 用户需求推动人工智能协作朝着安全、渐进的增强方向发展。

🆕 亚马逊Q开发者：2024-2025年最新功能

🔐 AWS帐户集成（游戏规则改变者）

直接访问AWS控制台：Q现在可以读取您的实际AWS资源、配置和部署
实时基础设施洞察：实时分析您的EC2、Lambda、S3、RDS和其他AWS服务
成本优化：根据您的实际AWS使用模式自动推荐
安全审计：AWS环境的实时安全态势分析
资源管理：缩放、优化和清理的智能建议

🚀 增强的开发功能

多语言掌握：对Python、JavaScript、TypeScript、Java、C#、Go、Rust和15种以上语言的高级支持
框架智能对React、Angular、Vue、Django、Flask、Spring Boot有深入的理解。NET和现代框架
基础设施即代码：专家级Terraform、CloudFormation、CDK和Pulumi协助
DevOps集成：CI/CD管道优化、Docker容器化、Kubernetes编排
数据库专业知识：高级SQL优化、NoSQL设计模式、数据库迁移策略

🧠 高级AI推理

架构分析：系统设计审查、微服务模式、可扩展性评估
性能分析：代码优化、瓶颈识别、效率提升
安全最佳实践：漏洞检测、安全编码模式、合规指导
测试策略：单元测试生成、集成测试、测试自动化框架
文档生成：自动API文档、代码注释、体系结构图

🔄 实时协作

实时代码审查：键入时进行持续分析，并提供智能建议
上下文保护：维护会话历史记录和项目理解
多项目意识：了解不同存储库和服务之间的关系
个人焦点：根据您的编码模式和偏好量身定制的个性化帮助

从以前版本解决的问题

v3问题已修复：

❌ MCP超时错误（-32001）
❌ 配置冲突（用户与工作区）
❌ 文件名损坏和换行
❌ JSON-RPC 2.0协议不合规
❌ 7台竞争的MCP服务器导致资源冲突
❌ 67%的代码重复和冗余
❌ 200-500ms启动时间
❌ 混合Python/Node.js实现

v4解决方案：

✅ 单个Node.js MCP服务器（启动时间\ “在项目项目中检测到内存使用率高”

2. 跨项目协调

Q同时管理多个Kiro项目：

“切换到项目X并在Y构建时运行测试”

3. 性能优化

Q分析模式并提出改进建议：

“考虑使用npm ci而不是npm install来实现更快的构建”

4. 发展援助

Q根据当前项目提供上下文感知帮助：

“我看到你正在研究kiro-q-bridge-v4。test.sh脚本显示所有通过的测试。"

🔒 安全特性

安全操作：只读状态监控
项目隔离：按项目标记但全局存储的消息
无命令执行：v4侧重于通信，而不是命令执行
审计跟踪：所有记录有时间戳和项目上下文的消息

贡献

这是一个开源项目。欢迎投稿！

分叉存储库
创建要素分支
进行更改
彻底测试
提交拉取请求

许可证

MIT许可证-有关详细信息，请参阅存储库。

🎉 核心优势：消除手动复制粘贴

✅ 不再复制粘贴 -直接的AI到AI通信消除了手动工作流程的摩擦\ ✅ 统一的人工智能体验 -Kiro和Q之间无缝协作，无需用户干预\ ✅ 上下文保护 -AI之间自动共享完整的对话上下文\ ✅ 实时协作 -人工智能可以在不破坏用户工作流程的情况下共同解决问题\ ✅ 持久共享内存 -两个AI系统都可以访问完整的对话历史记录\ ✅ 全球覆盖 -通过一致的沟通在所有Kiro项目中工作\ ✅ 快速可靠 -启动时间低于50毫秒，符合JSON-RPC 2.0协议

🔍 监控

查看消息历史记录：

# View all messages across projects
./view-messages.sh

# View messages for specific project  
./view-messages.sh my-project-name

# View raw message file
cat ~/.kiro/q-messages.json | jq .

实时状态： 使用 kiro_status 在Kiro中查看工具：

桥梁运行状态
当前项目检测
消息文件位置
服务器版本和类型

🚀 从v3迁移

如果您从v3升级，请参阅 V4_MIGRATION_GUIDE.md 详细说明。主要改进：

60+个文件→ 7 files：大幅简化的架构
python→ Node.js：更快的启动和更好的MCP集成
多台服务器→ 单台服务器：不再有配置冲突
项目特定文件→ 全球标签：更简单的管理

支持

问题：通过GitHub Issues报告bug
讨论：使用GitHub讨论提问
文档：有关详细设置，请参阅迁移指南
上一版本: 基罗q桥v3 （遗产）

______________________________________________________________________

Amazon Q现在可以成为您的AI配对编程合作伙伴，与Kiro积极合作！ 🤖🚀

制作❤️ Kiro IDE社区

🔧 故障排除

🔄 何时重新启动Kiro IDE

在执行以下操作后立即重新启动Kiro：

正在更新MCP服务器配置(.kiro/settings/mcp.json)
在桥接版本（v4.0）之间切换→ v4.3增强版）
安装新的MCP服务器或工具
持续>5分钟的MCP连接错误

90分钟规则： 如果故障排除工作在90分钟后仍未解决问题，请重新启动Kiro IDE。这将清除：

缓存的MCP连接
工具定义缓存
进程状态冲突
配置重新加载问题

常见问题

MCP连接错误：

检查中的服务器文件路径 .kiro/settings/mcp.json
验证服务器文件是否存在以及是否可执行
重新启动Kiro IDE以重新加载MCP配置
检查服务器日志中的特定错误消息

桥梁通信问题：

验证增强的网桥服务器是否在端口3847上运行
测试HTTP端点： curl http://localhost:3847/api/status
检查邮件文件权限： ~/.kiro/q-messages.json
重新启动网桥服务器和Kiro IDE

未找到工具错误：

确认MCP服务器配置正确
检查 autoApprove 所需工具的设置
重新启动Kiro IDE以刷新工具定义
验证服务器版本兼容性

Kiro Q Bridge

快速接入

详细介绍

Kiro-Q Bridge v4

Kiro IDE和Amazon Q Developer之间干净、快速、可靠的通信桥梁

🎉 功能演变亮点

🆕 v4.2-基于文档的协作（2025年11月）

🚀 v4.1-智能问题路由（2025年11月）

🌉 v4.0-双向桥梁（2025年10月）

📦 v3.0-生产就绪（2025年10月）

🏗️ v2.0-HTTP API桥接（2025年9月）

🌱 v1.0-初始桥梁（2025年9月）

🤝 Kiro+亚马逊Q开发者：直接AI到AI通信

🌟 消除聊天UI之间的手动复制粘贴

沟通问题已解决

Bridge的核心价值：消除工作流程摩擦

核心竞争力分析

Kiro IDE的优势

Kiro IDE限制

亚马逊Q开发者优势

亚马逊Q开发者限制

🚀 桥接器的特定优势（补充IDE插件）

1. 🔄 自动化开发智能

2. 📊 长期项目情报

3. ⚡ 工作流自动化

4. 🎯 重点用例

🎯 桥梁特定能力

🎯 桥接目的：直接AI到AI通信

🔒 反模拟安全措施（v4.2.1+）

🚀 v4.1-双向通信✅ 完成

🚀 v4.1+-具有实时协作功能的完整会话管理器✅ 完成

🚀 未来路线图：增强用户体验

🎭 实时协作示例：Kiro-Q的分歧与妥协

1.初步提案（Kiro）

2.不同意（Q通过桥）

3.呈现给用户的决策点

4.用户决策

5.妥协实施（Kiro）

6.协议与执行（Q via Bridge）

7.主动监测

演示的主要功能：

🎯 实时协作示例：代码质量增强项目

1.用户发起协作

2.Kiro向Q发送协作请求

3.Q的战略分析（通过Bridge）

4.用户决策和安全检查

5.实施和测试

6.自动会话管理

演示的主要功能：

🆕 亚马逊Q开发者：2024-2025年最新功能

🔐 AWS帐户集成（游戏规则改变者）

🚀 增强的开发功能

🧠 高级AI推理

🔄 实时协作

从以前版本解决的问题

2. 跨项目协调

3. 性能优化

4. 发展援助

🔒 安全特性

贡献

许可证

🎉 核心优势：消除手动复制粘贴

🔍 监控

🚀 从v3迁移

支持

🔄 何时重新启动Kiro IDE

常见问题

目录标签

接入字段

权限和风险

来源信息

继续浏览同类 MCP